Collapsing / expanding a splatted value can be replaced with a single `tensor.splat` operation. Replace
these cases with a simple `tensor.splat` operation.

Reviewed By: rsuderman

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

[mlir][sparse] Move some member functions from SparseTensorDescriptorImpl to MutSparseTensorDescriptor.

This is to prepare for implementing AOS optimization.

Reviewed By: aartbik

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

Offset is a signed value, so use `arith.sitofp`

See also https://github.com/llvm/llvm-project/issues/59585

Reviewed By: NatashaKnk, jpienaar

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

This reverts commit d5dd37ac.

Apparently there's some ABI difference in the Sony builder that fails a test.
Will hopefully investigate tomorrow. https://lab.llvm.org/buildbot/#/builders/139/builds/33769

Similar to D81251 for AArch64 BTI. This fixes `./a.out test` for

```
void foo(void) {}
void bar(void) {}
static void (*fptr)(void);
int main(int argc, char **argv) {
  if (argv[1]) fptr = foo;
  else fptr = bar;
  fptr();
}
```

`clang -flto=thin -fvisibility=hidden -fsanitize=cfi-icall -fcf-protection=branch -fuse-ld=lld a.cc`

Reviewed By: tejohnson

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

These appear to have had 32 bit check lines manually deleted - presumably since the checks are verbose.  Please don't do this!  Split the test file if you want, but manually deleting test lines makes the diffs for later autogen changes really confusing.

Reviewed By: bixia

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

These interceptors are pure forwarders for other sanitizers. Move them beside
tsan-specific pthread_mutex_{trylock,timedlock} interceptors.

While here, guard `__pthread_mutex_{lock,unlock}` (D46793) under `#if !__GLIBC_PREREQ(2, 34)`.

In glibc>=2.34 [1], `__pthread_mutex_{lock,unlock}` only have non-default-version definitions
(unversioned `__pthread_mutex_lock` causes a linker error. Program preloading is not expected).
In glibc>=2.36 [2], `dlsym(RTLD_NEXT, "__pthread_mutex_lock")` returns nullptr, so the interceptor won't work.

Fix https://github.com/llvm/llvm-project/issues/59820

[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=99f841c441feeaa9a3d97fd91bb3d6ec8073c982
[2]: https://sourceware.org/git/?p=glibc.git;a=commit;h=efa7936e4c91b1c260d03614bb26858fbb8a0204

Reviewed By: melver, vitalybuka

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

OpenCL requires constant string arguments to be in a particular address space,
so OpenCL sources can't use the regular `__nvvm_reflect()`.

Allow NVVMReflect pass to accept an Open_CL specific variant with a constant
string in a non-default address space.

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

The argument is hex digits, so <dir> doesn't make a lot of sense.

Reviewed By: phosek

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

This reverts commit 85960043.

The powerpc64le self-built buildbot had an assertion during self-build,
that seems like it is possibly related here, reverting so the author can
take a look.

https://alive2.llvm.org/ce/z/cLGpWV, but https://alive2.llvm.org/ce/z/TGNH4P

As noted in https://github.com/llvm/llvm-project/issues/59624, we sometimes mark implicitly
deleted special member functions as non-trivial. This is unnecessary work and leads to some
weird type traits errors.

This fixes the problem by making the implicitly deleted special member functions always
trivial.

Reviewed By: #clang-language-wg, erichkeane

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

Fix a windows buildbot failure: https://lab.llvm.org/buildbot#builders/13/builds/30439.

Previous to this patch we only materialized 0.0 and all other floating point
values would be loaded from the TOC. This patch adds materialization for the
floating point values that can be represented as integers in [-16.0, 15.0].

For example we will now materialize 3.0 and -5.0 but not 4.7.

Reviewed By: nemanjai, lei, #powerpc

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

This is needed because WGSL does not yet support extended multiplication
ops.

Set up pattern/pass stuff and handle the first op: `UMulExtended`.
`SMulExtended` handling will go to a separate patch.

Issue: https://github.com/llvm/llvm-project/issues/59563

Reviewed By: antiagainst

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

peek-through-shuffles, NFC.

By default, all benchmark results are analysed, but sometimes it may be useful
to only look at those that to not involve memory, or vice versa. This option
allows to either keep all benchmarks, or filter out (ignore) either all the
ones that do involve memory (involve instructions that may read or write to
memory), or the opposite, to only keep such benchmarks.

Personally, so far i have found the benchmarks that do involve memory
to have dubious results. But the ones that do not involve memory,
are generally actionable. So i would like to have a toggle to declutter results.

Reviewed By: courbet

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

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