Annotation metadata supports adding singular annotation strings to annotation block. This patch adds the ability to insert a tuple of strings into the metadata array.
The idea here is that each tuple of strings represents a piece of information that can be all related. It makes it easier to parse through related metadata information given it will be contained in one tuple.
For example in remarks any pass that implements annotation remarks can have different type of remarks and pass additional information for each.
The original behaviour of annotation remarks is preserved here and we can mix tuple annotations and single annotations for the same instruction.
Reviewed By: paquette
Differential Revision: https://reviews.llvm.org/D148328
The patch adds new member MaybeEVL into InterestingMemoryOperand to represent
the effective vector length for vp intrinsics. It may be extended for some target intrinsics in the future.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D146208
We are simplifying the loop and all its children. Each time, we
invalidate the top-most loop. The top-most loop is going to be
the same every time. The cost of SCEV invalidation is largely
independent from how data about the loop is actually cached, so
we should avoid redundant invalidations.
The asm in a naked function may reasonably expect the argument registers and the
return address register (if present) to be live.
When using -pg and -finstrument-functions, functions are instrumented by adding
a function call to `_mcount/__cyg_profile_func_enter/__cyg_profile_func_enter_bare`/etc,
which will clobber these registers. If the return address register is clobbered,
the function will be unable to return to the caller, possibly causing an
infinite loop.
```
__attribute__((naked)) void g() {
#if defined(__arm__)
__asm__("bx lr");
#else
__asm__("ret");
#endif
}
int main() { g(); }
```
It seems that the only one reasonable way to handle the combination is to
disable instrumenting for naked functions.
GCC PR: https://gcc.gnu.org/PR109707
Close https://github.com/llvm/llvm-project/issues/62504
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D149721
LCSSA currently invalidates SCEV for all instructions for which
LCSSA phi nodes are created. This used to be necessary, because
SCEV has historically tried to maintain LCSSA form as well. As
such, some SCEV uses of the value would have to become uses of
the phi node instead.
However, nowadays SCEV itself no longer maintains LCSSA form.
The SCEV of on LCSSA phi node will be the same as the SCEV of its
argument. LCSSA is instead maintained in the SCEVExpander.
As such, I believe it is no longer necessary to perform any SCEV
invalidation during LCSSA construction.
After this patch the ScalarEvolution argument to the LCSSA utilities
is no longer necessary -- I'll remove it in a followup NFC patch to
keep this patch more concise.
Differential Revision: https://reviews.llvm.org/D149435
Switch to the just updated versions of the API in tcmalloc that change
the name of the hot cold paramter to a reserved identifier __hot_cold_t.
This was based on feedback from Richard Smith, as I also need to add
some follow-on handling to clang so they are annotated properly.
Differential Revision: https://reviews.llvm.org/D149475
We already invalidate each individual instruction for which LCSSA
is formed in formLCSSAForInstructions(), so I don't see a reason
why we would need to invalidate the entire loop on top of that.
I believe we also no longer need the instruction-level invalidation
now that SCEV looks through LCSSA phis, but I'll leave that for a
separate patch, as it's less obvious.
Differential Revision: https://reviews.llvm.org/D149331
D129370 introduced the idea that hoisting could skip over non-matching
instructions and continue to look for matching (hoistable) instructions,
but certain types of mismatch still aborted the whole hoisting attempt.
Fix this by splitting out some of the instruction matching checks into a
helper function.
Also forbid hoisting allocas past stacksave/stackrestore, completing the
fix started in D133730, to avoid regressing tests.
Differential Revision: https://reviews.llvm.org/D149365
A ValueAsMetadata may be replaced with nullptr for several reasons including
deleting (certain) values and value remapping a use-before-def. In the case of
a MetadataAsValue user, handleChangedOperand intercepts and replaces the
metadata with an empty tuple (!{}).
At the moment, an empty metadata operand in a debug intrinsics signals that it
can be deleted.
Given that we end up with empty metadata operands in circumstances where the
Value has been "lost" the current behaviour can lead to incorrect variable
locations. Instead, we should treat empty metadata as meaning "there is no
location for the variable" (the same as we currently treat undef operands).
This patch removes the deletion logic from wouldInstructionBeTriviallyDead.
Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value
Reviewed By: StephenTozer
Differential Revision: https://reviews.llvm.org/D140901
zeroinitializer is allowed for spirv TargetExtType.
This PR allows ValueMapper to map TargetExtType ConstantTargetNone to '0' constant of its layout type.
Reviewed By: jcranmer-intel
Differential Revision: https://reviews.llvm.org/D148774
Original patch (50b2a113db197a97f60ad2aace8b7382dc9b8c31) ignored the
fact that -ftrivial-auto-var-init could affect function parameters with
the sret attribute.
Just do not move instruction that don't affect alloca.
Also add missing test case for volatile instruction.
Differential Revision: https://reviews.llvm.org/D148507
To track the return values of specializations, we need to invalidate all
the lattice values across the use-def chain which originates from the
callsites, recompute and propagate.
Differential Revision: https://reviews.llvm.org/D146158
This is by default on and I don't see any reason to turn it off. There's also no testing of it.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D148956
Fix case when FlattenCFGOpt combines the conditions but doesn't update
branch with a new combined condition. It happens when one of the
combinable condition is inverted and has more then 1 user
Patch by Aleksandr Popov!
Differential Revision: https://reviews.llvm.org/D148707
This exposed another miscompile in GVN, which was fixed by
20e9b31f88149a1d5ef78c0be50051e345098e41.
-----
After D141386, violation of nonnull, range and align metadata
results in poison rather than immediate undefined behavior,
which means that these are now safe to retain when speculating.
We only need to remove UB-implying metadata like noundef.
This is done by adding a dropUBImplyingAttrsAndMetadata() helper,
which lists the metadata which is known safe to retain on speculation.
Differential Revision: https://reviews.llvm.org/D146629
Fixes warning treated as error from
https://lab.llvm.org/buildbot/#/builders/13/builds/34440:
'llvm::LibCallSimplifier::optimizeNew': not all control paths return a value
after a35206d78280e0ebcf48cd21bc5fff5c3b9c73fa.
Change assert in default case to a return nullptr, so we have a
reasonable fallback if invoked on a different library function, and no
longer get the above warning.
These two math library functions can't write to errno, but they do
produce two results and store the second result to a pointer passed as
their second argument. Appropriately marking them as
memory(argmem: write) enables more optimizations on calls to them.
Reviewed By: xbolva00
Differential Revision: https://reviews.llvm.org/D148043
If the memset is large, checking every single byte of the global
may be very slow. Add an upper bound on the size of memset we
handle.
For the common special case of memset zeroinitializer to zero,
add a fastpath that checks just that and is not length limited.
Fixes https://github.com/llvm/llvm-project/issues/62191.
This patch replaces the uses of PointerUnion.is function by llvm::isa,
PointerUnion.get function by llvm::cast, and PointerUnion.dyn_cast by
llvm::dyn_cast_if_present. This is according to the FIXME in
the definition of the class PointerUnion.
This patch does not remove them as they are being used in other
subprojects.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D148449
This exposed a miscompile in GVN, which was fixed by D148129.
-----
After D141386, violation of nonnull, range and align metadata
results in poison rather than immediate undefined behavior,
which means that these are now safe to retain when speculating.
We only need to remove UB-implying metadata like noundef.
This is done by adding a dropUBImplyingAttrsAndMetadata() helper,
which lists the metadata which is known safe to retain on speculation.
Differential Revision: https://reviews.llvm.org/D146629
Last user of DemandedBitsWrapperPass was the BDCE pass. Since
the legacy PM version of BDCE was removed in an earlier commit, this
patch removes the now unused DemandedBitsWrapperPass.
Differential Revision: https://reviews.llvm.org/D148336
Remove C APIs for interacting with PassRegistry and pass
initialization. These are legacy PM concepts, and are no longer
relevant for the new pass manager.
Calls to these initialization functions can simply be dropped.
Differential Revision: https://reviews.llvm.org/D145043
I believe !dereferencable violation is immediate undefined behavior,
but this was not explicitly spelled out in LangRef. We already
assume that !dereferenceable is implicitly !noundef and cannot
return poison in isGuaranteedNotToBeUndefOrPoison().
The reason why we made dereferenceable implicitly noundef is that
the purpose of this metadata is to allow speculation, and that
would not be legal on a potential poison pointer.
Differential Revision: https://reviews.llvm.org/D148202
Based off D148215, when expanding a min/max reduction we should be creating min/max intrinsics directly instead of relying on instcombine to fold them back together.
This patch handles integer min/max cases. Hopefully we can add floating point support soon (at least for fastmath/nnan cases) - but we're missing some of the plumbing to pass the correct FMF to the intrinsic at the moment.
Differential Revision: https://reviews.llvm.org/D148221
No need to include CallGraphSCCPass.h from the IPO/Inliner.
Also removed the include of LegacyPassManager.h in a couple of files
that do not really depend on that header file.
Differential Revision: https://reviews.llvm.org/D148083
GVN load widening was disabled in D24096. This removes various
support code that is no longer relevant.
The way this works nowadays is that we return PartialAlias with
an offset from BasicAA and this gets passed on as a clobber by
MDA. However, PartialAlias will only be returned if the load is
properly nested inside the other load.
This just removes the bulk of the code, but some additional
cleanup can be done here now that we don't need to distinguish
between load and store cases.
This could also move initialization of sret args, causing actually
initialized parts of such return values to be uninitialized. See
discussion on the code review.
> As a result of -ftrivial-auto-var-init, clang generates instructions to
> set alloca'd memory to a given pattern, right after the allocation site.
> In some cases, this (somehow costly) operation could be delayed, leading
> to conditional execution in some cases.
>
> This is not an uncommon situation: it happens ~500 times on the cPython
> code base, and much more on the LLVM codebase. The benefit greatly
> varies on the execution path, but it should not regress on performance.
>
> This is a recommit of cca01008cc31a891d0ec70aff2201b25d05d8f1b with
> MemorySSA update fixes.
>
> Differential Revision: https://reviews.llvm.org/D137707
This reverts commit 50b2a113db197a97f60ad2aace8b7382dc9b8c31
and follow-up commit ad9ad3735c4821ff4651fab7537a75b8f0bb60f8.
We have now seen two miscompiles because of widening widenable
conditions at incorrect IR points and thereby changing a branch's loop
invariant condition to a loop-varying one (see PR60234 and PR61963).
This patch adds asserts in common guard utilities that we use for
widening to proactively catch these bugs in future.
Note that these asserts will not fire if we were to sink a widenable
condition from out of a loop into a loop (that's also incorrect for the
same reason as above).
Tested this without the fix for PR60234 (guard widening miscompile) and
confirmed the assert fires.
WARNING: Sometimes, the assert can fire if we failed to hoist the
invariant condition out of the loop. This is a pass-ordering issue or a
limitation in LICM, which would need an investigation. See details in
review.
Differential Revision: https://reviews.llvm.org/D147752
