While we have great handling for UNDEF operands,
FREEZE-UNDEF operands are effectively normal operands.

We are better off "interleaving" such BUILD_VECTORS into a blend
between a splat of FREEZE-UNDEF, and "thawed" source BUILD_VECTOR,
both of which are more natural for us to handle.

Refs. https://github.com/llvm/llvm-project/commit/f738ab9075f838dd4365adf3a92ca1acced114d7#r95017306

To JIT kernels for AMDGPUs we need to provide the architecture, the
triple, and a post-link callback. The first two are simple, the last one
is a little more complicated since we need to invoke `lld`. There is
some library interface but for that we need the lld library, which is
not generally available, thus we go with the executable for now. In
either way we need to manifest the (amdgcn) object file and read the
output from another file. We should try to avoid that in the future.
The options for `lld` are copied from the way clang invokes it.

Reviewed By: tianshilei1992

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

We shouldn't penalize instructions that have extra flags.

Drop the poison-generating flags if needed instead of bailing out.
This makes canonicalization/optimization more uniform.

There is a chance that dropping flags will cause some
other transform to not fire, but we added a preliminary
patch to avoid that with:
f0faea57

See D140665 for more details.

The magic algorithm sets IsAdd indication for division by 1 that
the caller had to ignore.

I considered folding the ignore into UnsignedDivisionByConstantInfo,
but we only allow 1 for vectors of mixed visiors. And really what we
want to end up with is undef. Currently, we get to undef via
DemandedElts optimizations using the select instruction. We could
directly emit undef.

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

The pass should help to close a functional gap when it comes to
reasoning about related conditions in a relatively general way.

It addresses multiple existing issues (linked below) and the need for a
more powerful reasoning system was also discussed recently in
https://discourse.llvm.org/t/rfc-alternative-approach-of-dealing-with-implications-from-comparisons-through-pos-analysis/65601/7

On AArch64, the new pass performs ~2000 simplifications on
MultiSource,SPEC2006,SPEC2017 with -O3.

Compile-time impact:

NewPM-O3: +0.20%
NewPM-ReleaseThinLTO: +0.32%
NewPM-ReleaseLTO-g: +0.28%

https://llvm-compile-time-tracker.com/compare.php?from=f01a3a893c147c1594b9a3fbd817456b209dabbf&to=577688758ef64fb044215ec3e497ea901bb2db28&stat=instructions:u

Fixes #49344.
Fixes #47888.
Fixes #48253.
Fixes #49229.
Fixes #58074.

Reviewed By: asbirlea

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

Reviewed By: bixia

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

This patch allows AMDGPUUnifyDivergenceExitNodes pass
to transform a function whose PDT has exactly one root
and ends in a branch instruction. Fixes
https://github.com/llvm/llvm-project/issues/58861.

Reviewed By: ruiling, arsenm

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

This check was previous disabled because the test kept failing on ARM64. The output from reported failure message
gave the impression that the bundle was created as an x86-64 bundle but upon further inspection, I believe that's
a bug in llvm-otool where it prints both -h and -f for both input files on ARM64.

So the "fix" here is to rewrite the test to run the two otool commands separately but concatenate the
output into one file for checking.

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

Comment is stale now that kDynamic is defined as intmin instead of -1.

Confirmed that implementation in `parseDimensionListRanked` uses kDynamic.

Reviewed By: ftynse

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

The arguments are passed as stored to new allocas so the address space
needs to match.

Check lines for some of these tests were regenerated. The difference
is that with opaque pointers SCEVExpander always emits i8 GEPs,
making the address calculation explicit. This is a known problem
that will be solved long term by making all address calculations
explicit.

Return failure if the import of a global variable fails and add a
test case to check the emitted error message. Additionally, convert
the globals in iteration order and do not process them recursively
when translating a constant expression referencing it. Additionally,
use the module location rather unknown location.

Reviewed By: Dinistro

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

Part of the project to eliminate special handling for triples in lit
expressions.

Originally, the code would take a lookup result as a member in the
current scope and build a member expression accordingly, if the lookup
result was not an operand of the address operator, or it was a field
declaration. However, a field declaration may come from another class,
and cause the issue #58674.

Thus, this patch fixes the issue via checking where does the field
declaration comes from, and if it comes from another class, then marks
it as not member in the current scope. The parent scopes of the current
scope are also checked, as the current scope may be associated to a
lambda or friend declaration.

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

[mlir][sparse] Add layout to the memref for the indices buffers to prepare for the AOS storage optimization for COO regions.

Fix relevant FileCheck tests.

Reviewed By: aartbik

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

This should address the issue found in:
https://lab.llvm.org/buildbot/#/builders/30/builds/30330

The llvm.lifetime.start intrinsic guarantees that the address for a
given alloca is always the same. So variables with escaped addresses
reaching reaching a lifetime start/end block before and after a suspend
must be placed onto the coroutine frame even if the variable itself
is not alive across the suspend point.

This computes a new `LoopKill` flag in the suspend crossing data flow
anaysis to catch the case where a lifetime marker can reach itself
via suspend-crossing path.

This fixes https://llvm.org/PR52501

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

Strip pointer casts instead of matching specific constant
expressions.