Regression from 2f497ec3; we should not try to generate ldrexd on
targets that don't have it.

Also, while I'm here, fix shouldExpandAtomicStoreInIR, for consistency.
That doesn't really have any practical effect, though.  On Thumb targets
where we need to use __sync_* libcalls, there is no libcall for stores,
so SelectionDAG calls __sync_lock_test_and_set_8 anyway.

SLP is currently assuming that control dependence in these cases is irrelevant.  This is only valid if none of the lib-funcs involved can throw or infinite loop in the scalar forms.  This appears to be true (or at least we infer the respective attributes) for the libfuncs I spot checked.  This change is mostly for shrunking the diff on an upcoming patch.

ExpandShapeOp builder cannot infer the result type since it doesn't know
how the dimension needs to be split. Remove this builder so that it
doesn't get used accidently. Also remove one potential path using it in
generic fusion.

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

AVX512BWVL capable cpus are required 512-bit gfni

We already have rotation coverage

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterposable` is an insufficient condition.

Moreover, a non-preemptible alias may be referenced in a sub constant expression
which intends to lower to a PC-relative relocation. Replacing the alias with a
preemptible aliasee may introduce a linker error.

Respect dso_preemptable and suppress optimization to fix the abose issues. With
the change, `alias = 345` will not be rewritten to use aliasee in a `-fpic`
compile.
```
int aliasee;
extern int alias __attribute__((alias("aliasee"), visibility("hidden")));
void foo() { alias = 345; } // intended to access the local copy
```

While here, refine the condition for the alias as well.

For some binary formats like COFF, `isInterposable` is a sufficient condition.
But I think canonicalization for the changed case has little advantage, so I
don't bother to add the `Triple(M.getTargetTriple()).isOSBinFormatELF()` or
`getPICLevel/getPIELevel` complexity.

For instrumentations, it's recommended not to create aliases that refer to
globals that have a weak linkage or is preemptible. However, the following is
supported and the IR needs to handle such cases.
```
int aliasee __attribute__((weak));
extern int alias __attribute__((alias("aliasee")));
```

There are other places where GlobalAlias isInterposable usage may need to be
fixed.

Reviewed By: rnk

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

With D107249 I saw huge compile time regressions on a module (150s ->
5700s). This turned out to be due to a huge RefSCC in
the module. As we ran the function simplification pipeline on functions
in the SCCs in the RefSCC, some of those SCCs would be split out to
their RefSCC, a child of the current RefSCC. We'd skip the remaining
SCCs in the huge RefSCC because the current RefSCC is now the RefSCC
just split out, then revisit the original huge RefSCC from the
beginning.  This happened many times because many functions in the
RefSCC were optimizable to the point of becoming their own RefSCC.

This patch makes it so we don't skip SCCs not in the current RefSCC so
that we split out all the child RefSCCs on the first iteration of
RefSCC. When we split out a RefSCC, we invalidate the original RefSCC
and add the remainder of the SCCs into a new RefSCC in
RCWorklist. This happens repeatedly until we finish visiting all
SCCs, at which point there is only one valid RefSCC in
RCWorklist from the original RefSCC containing all the SCCs that
were not split out, and we visit that.

For example, in the newly added test cgscc-refscc-mutation-order.ll,
we'd previously run instcombine in this order:
f1, f2, f1, f3, f1, f4, f1

Now it's:
f1, f2, f3, f4, f1

This can cause more passes to be run in some specific cases,
e.g. if f1<->f2 gets optimized to f1<-f2, we'd previously run f1, f2;
now we run f1, f2, f2.

This improves kimwitu++ compile times by a lot (12-15% for various -O3 configs):
https://llvm-compile-time-tracker.com/compare.php?from=2371c5a0e06d22b48da0427cebaf53a5e5c54635&to=00908f1d67400cab1ad7bcd7cacc7558d1672e97&stat=instructions

Reviewed By: asbirlea

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

ASSERT_THAT_EXPECTED implicitly calls takeError(), and calling
takeError() a second time returns nothing, so the check for the
content of the error text wasn't being executed.
Fixes Issue #48901

Found by the Rotten Green Tests project.

 Adds basic parsing/sema/serialization support for the
 #pragma omp target teams loop directive.

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

Fixes llvm-clang-x86_64-expensive-checks-debian failure with 2f497ec3.

expandAtomicStore always modifies the function, so make sure we set
MadeChange unconditionally. Not sure how nobody else has stumbled over
this before.

This is a follow up to 565603cc,
which made macOS the default target OS for `-arch arm64` when
running on an Apple Silicon Mac. Now it'll be the default when
running on an Intel Mac too.

clang/test/Driver/apple-arm64-arch.c was a bit odd before: it was added
for the above commit, but tested the inverse behaviour and XFAIL'ed on
Apple Silicon. This inverts it to the (new) behaviour (that's now
correct regardless) and removes the XFAIL.

Radar-Id: rdar://90500294

This is incomplete and will handle more instructions as they are added.

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

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

GFX940 repurposes BLGP as NEG only in DGEMM MFMA.

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

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

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

Without this patch, clang would generate calls to __sync_* routines on
targets where it does not make sense; we can't assume the routines exist
on unknown targets. Linux has special implementations of the routines
that work on old ARM targets; other targets have no such routines. In
general, atomics operations which aren't natively supported should go
through libatomic (__atomic_*) APIs, which can support arbitrary atomics
through locks.

ARM targets older than v6, where this patch makes a difference, are rare
in practice, but not completely extinct. See, for example, discussion on
D116088.

This also affects Cortex-M0, but I don't think __sync_* routines
actually exist in any Cortex-M0 libraries. So in practice this just
leads to a slightly different linker error for those cases, I think.

Mechanically, this patch does the following:

- Ensures we run atomic expansion unconditionally; it never makes sense to
completely skip it.
- Fixes getMaxAtomicSizeInBitsSupported() so it returns an appropriate
number on all ARM subtargets.
- Fixes shouldExpandAtomicRMWInIR() and shouldExpandAtomicCmpXchgInIR() to
correctly handle subtargets that don't have atomic instructions.

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

This reverts commit 21b97df7.
6316129e relanded in 7b983917.

Reviewed By: ldionne, Mordante, #libc

Spies: var-const, aheejin, libcxx-commits

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

This re-lands 6316129e after fixing the condition logic.

The new flag seems to not be working yet on Windows, where the builtin
trap isn't "no return".

Reviewed By: dexonsmith

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

It knows the size, so no need to call reserve beforehand. NFCI.

For constant indices, these are now just a MOVMSK+TEST/BT

I keep thinking this assumption is probably exploitable for a bug in the existing implementation, but all of my attempts at writing a test case have failed.  So for the moment, just document this very subtle assumption.

This patch fixes:

  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:3917:13: error:
  unused function 'needToScheduleSingleInstruction'
  [-Werror,-Wunused-function]

This patch fixes:

  llvm/lib/Target/VE/VVPISelLowering.cpp:186:11: error: unused
  variable 'PassThru' [-Werror,-Wunused-variable]

This patch fixes:

  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp:8148:18: error:
  unused variable 'SDTE' [-Werror,-Wunused-variable]

[SCCP] do not clean up dead blocks that have their address taken

Fixes a crash observed in IPSCCP.

Because the SCCPSolver has already internalized BlockAddresses as
Constants or ConstantExprs, we don't want to try to update their Values
in the ValueLatticeElement. Instead, continue to propagate these
BlockAddress Constants, continue converting BasicBlocks to unreachable,
but don't delete the "dead" BasicBlocks which happen to have their
address taken.  Leave replacing the BlockAddresses to another pass.

Fixes: https://github.com/llvm/llvm-project/issues/54238
Fixes: https://github.com/llvm/llvm-project/issues/54251

Reviewed By: nikic

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

Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.

Reviewed By: #libc, philnik, EricWF

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

This reverts commit 1cfa986d.  See https://github.com/llvm/llvm-project/issues/54256 for why I'm discontinuing the project.

Seperately, it turns out that while this patch does correctly preserve MSSA, it's correct only at the end of the pass; not between vectorization attempts.  Even if we decide to resurrect this, we'll need to fix that before reapplying.

Quote from the LLVM Language Reference
  If ptr is a stack-allocated object and it points to the first byte of the
  object, the object is initially marked as dead. ptr is conservatively
  considered as a non-stack-allocated object if the stack coloring algorithm
  that is used in the optimization pipeline cannot conclude that ptr is a
  stack-allocated object.

By replacing the alloca pointer with the tagged address before this change,
we confused the stack coloring algorithm.

Reviewed By: eugenis

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

Minor fixes needed and now `./bin/lldb-dotest -p TestTrace` passes
correctly.

- There was an incorrect iteration.
- Some error messages changed.
- The way repeat commands are handled changed a bit, so I had to create
a new --continue arg in "thread trace dump instructions" to handle this
correctly.

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

This reverts commit f66d3758.

It breaks windows bot.

https://reviews.llvm.org/D23944 implemented the #pragma intrinsic from
MSVC. This causes the statement #pragma intrinsic(cpuid) to fail [0]
on Clang because cpuid is currently implemented in intrin.h instead
of a Clang builtin. Reimplementing cpuid (as well as it's releated
function, cpuidex) should resolve this.

[0]: https://crbug.com/1279344

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

We want to build all available ones.

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

This is useful when developing on Windows.

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