This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675

Revert "[clang] Fix a clang crash on invalid code in C++20 mode."

This reverts commit 32d7aae0.

Revert "[clang] Remove overly restrictive aggregate paren init logic"

This reverts commit c77a91bb.

Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"

This reverts commit 40c52159.

The pruning property that's part of the DIE info is fully computing
during the analyzeContextInfo phase, but can be updated during the
lookForDIEsToKeep phase.

  // Keep a module forward declaration if there is no definition.
  if (!(isODRAttribute(AttrSpec.Attr) && Info.Ctxt &&
        Info.Ctxt->hasCanonicalDIE()))
    Info.Prune = false;

When the pruning property is updated during the lookForDIEsToKeep phase,
it's not propagated to the parent, unlike during the analyzeContextInfo
phase. This can result in an invalid keep chain with the child DIE being
marked as kept while its parent is still marked as pruned and therefore
never kept, a situation that's now caught by 1b79bed8.

This patch fixes this issue by updating the pruning properties of the
parent DIE during the parent walk.

Differential revision: https://reviews.llvm.org/D140930

 - Remove always-false flag.
 - Remove unused return value.

Changing element type seems to not play well with non-simple types,
even though we are operating on EVT's here.

These weren't previously getting combined at all here,
only in target-specific combines.

This appears to be the root problematic pattern
for AArch64 regression in D140677.

We already do this, and many more, as target-specific X86 combines,
so this isn't causing much of an impact.

To be used in an upcoming patch.

Switch Tosa_IntArrayAttr[N], Tosa_IntArrayAttrUpto[N] to DenseI64ArrayAttr.

Test plan: ninja check-mlir check-all

Differential revision: https://reviews.llvm.org/D140748 https://reviews.llvm.org/D140829, https://reviews.llvm.org/D140832, https://reviews.llvm.org/D140833, https://reviews.llvm.org/D140834

The arm64 register context on Darwin has the 29 general purpose
registers, then pc/sp/lr/fp with different field names depending
on compile-time flags.  Instead of accessing beyond the end of
the uint64_t[29] array, and upsetting the sanitizers, access those
registers correctly with the correct name.

Fixes a test failure on the ASAN CI bot, currently being
skipped, in TestEarlyProcessLaunch.py.

Differential Revision: https://reviews.llvm.org/D140067
rdar://103359354

Previously, CFA_remember_state stored only the register locations but ignored the CFA value. This needs also to be remembered and restored for correct behavior. The problem occurs, e.g., on functions with multiple epilogues, where the CFA value after the first epilogue is becomes wrong.

Reviewed By: #debug-info, MaskRay

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

This reverts commit aa241472.

Previously-valid IR from a tensorflow test case (as shown on the
Diffusion revision for aa241472) started
hanging in the loop-vectorize pass. Reverting to keep everyone working.

analysis.

Missed the analysis of the shuffle mask when trying to analyze the
operands of the shuffle instruction during peeking through shuffle
instructions.

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