Without this patch, if an incompatible libomptarget.so is present in a
system directory, such as /usr/lib64, check-openmp fails many
libomptarget tests with linking errors.  The problem appears to have
started at D129875, which landed as dc52712a.  This patch extends
the libomptarget test suite config with a -L for the current build
directory of libomptarget.so.

Reviewed By: jhuber6, JonChesterfield

Differential Revision: https://reviews.llvm.org/D149391

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

Shift and fdiv tests have been added to show the reverse transform.

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

This reverts commit 35af20d9.

The patch caused a test failure.

This commit fixes a compilation error introduced in
https://reviews.llvm.org/D149361

Reviewed By: gysit

Differential Revision: https://reviews.llvm.org/D149434

The test case for signed max with index, include strict and non-strict
max.

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D146718

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

A new attempt after removing uses of -instnamer in polly lit tests
in D148530.

Differential Revision: https://reviews.llvm.org/D148530

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

Patch by Aleksandr Popov!

Differential Revision: https://reviews.llvm.org/D149373

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 0ba922f6 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

This reverts commit f2404d58,
which causes failures on Windows.

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

Also contains an extra test mentioned in D144434.

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

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D148518

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

[hwasan][test] add test for hwasan-check-memaccess when hwasan-match-all-tag flag and short granules both used

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D149399

This reverts commit 876df74d.

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

The diagnostics have changed from "unexpected token" to clearer "expected newline"

Looks like HWASAN_ALIASING_MODE work around.
But any tagged pointer should be mapped, so load
should work.

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

Having `A == B` is quite common for rotate patterns.

Alive2 Links:
    - https://alive2.llvm.org/ce/z/mPXi9c
    - https://alive2.llvm.org/ce/z/UfDHoI

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D149372

Differential Revision: https://reviews.llvm.org/D149371