Changes

[hwasan] Use stack safety analysis.

This avoids unnecessary instrumentation.

Reviewed By: eugenis, vitalybuka

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

[VE] Set getExtendForAtomicOps to ISD::ANY_EXTEND

The implementation of subword atomics does not actually
guarantee the result is zero-extended, which now caused
failures after https://reviews.llvm.org/D101342 was landed.

Reviewed By: simoll

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

[ORC-RT] Fix missing std::move.

This should fix the 'could-not-covert' error at wrapper_function_utils.h:128 in
https://lab.llvm.org/buildbot/#/builders/112/builds/7748.

[ORC] Drop 'const' for __orc_rt_CWrapperFunctionResultDataUnion::ValuePtr.

This member is now only used when storage is heap-allocated so it does not
need to be const. Dropping 'const' eliminates cast warnings on many builders.

tsan: make obtaining current PC faster

We obtain the current PC is all interceptors and collectively
common interceptor code contributes to overall slowdown
(in particular cheaper str/mem* functions).

The current way to obtain the current PC involves:

  4493e1:       e8 3a f3 fe ff          callq  438720 <_ZN11__sanitizer10StackTrace12GetCurrentPcEv>
  4493e9:       48 89 c6                mov    %rax,%rsi

and the called function is:

uptr StackTrace::GetCurrentPc() {
  438720:       48 8b 04 24             mov    (%rsp),%rax
  438724:       c3                      retq

The new way uses address of a local label and involves just:

  44a888:       48 8d 35 fa ff ff ff    lea    -0x6(%rip),%rsi

I am not switching all uses of StackTrace::GetCurrentPc to GET_CURRENT_PC
because it may lead some differences in produced reports and break tests.
The difference comes from the fact that currently we have PC pointing
to the CALL instruction, but the new way does not yield any code on its own
so the PC points to a random instruction in the function and symbolizing
that instruction can produce additional inlined frames (if the random
instruction happen to relate to some inlined function).

Reviewed By: vitalybuka, melver

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

Revert "[hwasan] Use stack safety analysis."

This reverts commit 12268fe14a1a65d4b62f0b6e5beab46ba8501ae7.

[LV] Add test with ptr induction used as scalar and vector.

Test case inspired by D105199.

[mlir][memref] Clarify the documentation for memref.clone [NFC]

The wording was wrong and suggested that operands to memref.clone may not be mutated.

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

[LV] Re-generate check lines of some fragile tests (NFC)

Reviewed By: fhahn

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

[LoopUtils] Fix incorrect RT check bounds of loop-invariant mem accesses

This fixes the lower and upper bound calculation of a
RuntimeCheckingPtrGroup when it has more than one loop
invariant pointers. Resolves PR50686.

Reviewed By: fhahn

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

[SLP]Fix possible crash on unreachable incoming values sorting.

The incoming values for PHI nodes may come from unreachable BasicBlocks,
need to handle this case.

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

[CostModel][X86] Add fast math tests for float reductions

As noticed on D105432 we didn't have any coverage to distinguish between fast/exact float reductions

[ORC-RT] Separate jit-dispach tag decls from definitions.

This should eliminate the "initialized and declared 'extern'" warnings produced
on some bots, e.g. https://lab.llvm.org/buildbot/#/builders/165/builds/3770

[ORC-RT] Introduce a weak-import macro.

This should eliminate warnings about ignored weak_import attributes on some of
the bots, e.g. https://lab.llvm.org/buildbot/#/builders/165/builds/3770/.

[mlir] Introduce `linalg.tiled_yield` terminator for `linalg.tiled_loop`.

https://llvm.discourse.group/t/rfc-changes-to-linalg-tiledloopop-to-unblock-reductions/3890

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

[rt][nfc] Rewrite #ifndef as #if defined().

[clang-tidy] ensure run-clang-tidy reports children killed by signals

If a clang-tidy child process exits with a signal then run-clang-tidy will exit
with an error but there is no hint why in the output, since the clang-tidy
doesn't log anything and may not even have had the opportunity to do so
depending on the signal used.

`subprocess.CompletedProcess.returncode` is the negative signal number in this
case.

I hit this in a CI system where the parallelism used exceeded the RAM assigned
to the container causing the OOM killer to SIGKILL clang-tidy processes.

Reviewed By: sylvestre.ledru

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

Revert "[mlir] Introduce `linalg.tiled_yield` terminator for `linalg.tiled_loop`."

This reverts commit 3b03d9b874aa902f7f969e7ffdefde23c2758eeb.

[clang] Change set type used for SourceLocation.

This is part of a patch series working towards the ability to make
SourceLocation into a 64-bit type to handle larger translation units.

If clang is built for a 32-bit platform and SourceLocation is 64 bits
wide, then a SourceLocation will be larger than a pointer, so it won't
be possible to keep them in a SmallPtrSet any more. Switch to
SmallDenseSet instead.

Patch originally by Mikhail Maltsev.

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

[AMDGPU] Fix typo in comments idexen -> idxen

Fix duplicate checks in clangd comments

This patch removes a duplicate checks in the top-level comments in `clang-tools-extra/clangd/ParsedAST.h`

Reviewed By: kadircet

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

[MLIR] AffineStructures: resolve clang-tidy warnings [NFC]