On AIX, when the input files are LLVM bitcode files, `llvm-ar` should set the archive kind to `K_AIXBIG` as well, instead of leaving it to the default `K_GNU`.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D149377
Clang accepts preserve_all for AArch64 while it is missing form the backed.
Fixes#58145
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D135652
When invalidating a value, we walk all users of that value and
invalidate them as well. This can be very expensive for large use
graphs.
However, we only need to invalidate a user U of instruction I if
SCEV(U) can depend on SCEV(I). This is not the case if U is an
instruction that always produces a SCEVUnknown, such as a load.
If the load pointer operand is invalidated, there is no need to
invalidate the load result, which is completely unrelated from a
SCEV perspective.
Differential Revision: https://reviews.llvm.org/D149323
D37076 makes LICM duplicate instructions into exit blocks if the
instruction is free. For GEPs, the motivation appears to be that
this allows the GEP to be folded into addressing modes, while
non-foldable users outside the loop might prevent this. TBH I don't
think LICM is the place to do this (why doesn't CGP apply this
heuristic itself?) but at least I understand the motivation.
However, the transform is also applied to all other "free"
instructions, which are just that (removed during lowering and not
"folded" in some way). For such instructions, this transform seems
somewhere between useless, counter-productive (undoing CSE/GVN) and
actively incorrect. For example, this transform can duplicate freeze
instructions, which is illegal.
This patch limits the transform to just foldable GEPs, though we
might want to drop it from LICM entirely as a followup.
This is a small compile-time improvement, because querying TTI cost
model for every single instruction is expensive.
Differential Revision: https://reviews.llvm.org/D149136
The entry to the plan is the preheader of the vector loop and
guaranteed to be a VPBasicBlock. Make sure this is the case by
adjusting the type.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D149005
expr.prim.lambda.capture p5 says:
If an identifier in a capture appears as the declarator-id of a parameter of
the lambda-declarator's parameter-declaration-clause or as the name of a
template parameter of the lambda-expression's template-parameter-list,
the program is ill-formed.
and also has the following example:
```
auto h = [y = 0]<typename y>(y) { return 0; };
```
which now results in
```
error: declaration of 'y' shadows template parameter
auto l1 = [y = 0]<typename y>(y) { return 0; };
^
note: template parameter is declared here
auto l1 = [y = 0]<typename y>(y) { return 0; };
^
```
Fixes https://github.com/llvm/llvm-project/issues/61105
Reviewed By: shafik, cor3ntin
Differential Revision: https://reviews.llvm.org/D148712
This change the types to match the ones used in:
Darwin/debug_external.cpp
debugging.cpp
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D148214
See https://discourse.llvm.org/t/rfc-enable-assignment-tracking/69399
This sets the -Xclang -fexperimental-assignment-tracking flag to the value
enabled which means it will be enabled so long as none of the following are
true: it's an LTO build, LLDB debugger tuning has been specified, or it's an O0
build (no work is done in any case if -g is not specified or -gmlt is used).
This reverts commit 0ba922f600 which reverts
https://reviews.llvm.org/D146987
The working of depend clause with iterator modifier
can be correctly tested by means of execution tests
and not at the LLVM IR level. These tests
are imported/inspired from the SOLLVE tests.
SOLLVE repo: https://github.com/SOLLVE/sollve_vv
Differential Revision: https://reviews.llvm.org/D146706
Following the changes in D145301, we now also support the efficient bitcast
when storing the bool vector. Previously, this was expanded.
Differential Revision: https://reviews.llvm.org/D148316
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
This patch changes the shufflevector's semantics to yield poison if the mask is undefined.
This allows the extraction of shufflevectors while also opening the door for more
optimization opportunities due to the fact that poison is more undefined than undef.
Differential Revision: https://reviews.llvm.org/D148637
With a similar reason as D148023; some applications make heavy use of
the CRC32 intrinsic (e.g., as part of a hash function) and therefore
benefit from avoiding frequent SelectionDAG fallbacks. In our
application, we get a 2% compile-time improvement.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D148917
This defines more equivalent base SD opcodes for various VP nodes, so
that getVPForBaseOpcode can do more lookups of VP-equivalent operations.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D148520
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
As far as I understand, the IsAvailableOnEntry() function basically
implements the same functionality as the properlyDominates() block
disposition. The primary difference (apart from a weaker
implementation) seems to be in this comment at the top:
// Checks if the SCEV S is available at BB. S is considered available at BB
// if S can be materialized at BB without introducing a fault.
However, I don't really understand why there would be such a
requirement. It's my understanding that SCEV explicitly does not
care about trapping udiv instructions itself, and it's the job of
SCEVExpander's isSafeToExpand() to make sure these don't get
expanded if they may trap.
Differential Revision: https://reviews.llvm.org/D149344
When hwasan-match-all-tag flag is enabled and short granules are used, at the point checking if this is a short tag case, the tag from pointer is stored in X16 register,
which breaks the assumption that tag from shadow memory is stored in X16 register, this will cause a false positive.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D149252
This reverts commit 876df74dd4.
My understanding (based on https://reviews.llvm.org/D149429) is that
this patch has caused all of Flang's buildbots to fail. I'm not really
able to verify 100% as the buildbot UI is incredibly slow ATM. I am
reverting either way so that we can discuss the right solution offline.
Without this patch, in `getAssignmentInfo` the result of `getTypeSizeInBits` is
cast to `uint64_t`, which a) is an operation that will eventually be
unsupported by the API according to the comments, and b) causes an assertion
failure if the type is a scalable vector. Don't cast the `TypeSize` to
`uint64_t` and check `isScalable` before getting the fixed size.
This can result in incorrect variable locations, see llvm.org/PR62346 (but is
better than crashing).
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D149137
First, in CodeGenPrepare.cpp, line 6891, the VectorCond will always be false
because if not function will return at 6888.
Second, in SelectionDAGBuilder.cpp, line 5443, getSExtValue() will return
value as int type, but now we use unsigned Val to maintain it, which make the
if condition at 5452 meaningless.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D149033
Phis that are present inside loop headers can only be Induction Phis
legally. This patch adds an assertion to isInductionPhi which checks for
the said legality and it also updates the docs of the said function to
reflect the given legality.
Differential Revision: https://reviews.llvm.org/D149041
Add support to generate the acc.bound operation when the array is passed without
any subscripts. Without this patch, no bound is generated.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D149297
Relocations R_AVR_LO8_LDI_GS/R_AVR_HI8_LDI_GS (indirect calls
via function pointers) only cover range 128KiB. They are
equivalent to R_AVR_LO8_LDI_PM/R_AVR_HI8_LDI_PM within this
range.
But for function addresses beyond this range, GNU-ld emits
trampolines. And this patch implements corresponding thunks
for them in lld.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D147364
https://reviews.llvm.org/D149386 caused a buildbot error (https://lab.llvm.org/buildbot#builders/37/builds/21766):
'In file included from /b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/hwasan/hwasan_interceptors.cpp:18:
/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/hwasan/hwasan_checks.h:128:53: error: 'static' function 'PossiblyShortTagMatches' declared in header file should be declared 'static inline' [-Werror,-Wunneeded-internal-declaration]
__attribute__((always_inline, nodebug)) static bool PossiblyShortTagMatches('
This patch simply adds the inline annotation.
Differential Revision: https://reviews.llvm.org/D149402
Add --undefined=_QQmain to the link line, so that a Fortran main program
will be included in the link job even if it is in an archive (unless we
are building a shared object). For now, this is only applied to the Gnu
toolchain.
We also add a section on the linker invocation to docs/FlangDriver.md.
The new tests require llvm-ar to construct an archive we can include in
the link job. This is a new dependency for flang/test (which already
depends on similar tools such as llvm-objdump).
See discussions in
https://github.com/llvm/llvm-project/issues/54787
which this patch fixes.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D134821
This patch implements the `exit` function on the GPU. This required
breaking the entrypoints calling eachother on `linux` since this doesn't
work with a non-aliased target. This is only partial support because
full support requires a malloc / free implementation for the exit
callbacks array.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149363
This patch simply enables building the integer `abs` functions for the
GPU.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149317
This patch enables us to use the existing `libc` support for string
conversion functions on the GPU. This required setting the `fenv_t` and
long double configuration. As far as I am aware, long doubles are
converted to doubles on the GPU and the floating point environment is
just an `uint32_t`.
This code is still untested as we are still working out how to run the
unit tests on the GPU.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D149306
