Changes

[zorg] [PowerPC] Limit number of threads to 64 on clang-ppc64le-rhel buildbot

This patch reduces the number of threads from 256 to 64 on the
clang-ppc64le-rhel buildbot.

Reviewed By: stefanp

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

Move AffineMapAttr into BaseOps.td

AffineMapAttr is already part of base, it's just impossible to refer to
it from ODS without pulling in the definition from Affine dialect.

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

[sanitizers] Fix internal__exit on Solaris
`TestCases/log-path_test.cpp` currently `FAIL`s on Solaris:

  $ env ASAN_OPTIONS=log_path=`for((i=0;i<10000;i++)); do echo -n $i; done`  ./log-path_test.cpp.tmp
  ==5031==ERROR: Path is too long: 01234567...
  Segmentation Fault (core dumped)

The `SEGV` happens here:

  Thread 2 received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 1 (LWP 1)]
  0x00000000 in ?? ()
  (gdb) where
  #0  0x00000000 in ?? ()
  #1  0x080a1e63 in __interceptor__exit (status=1)
      at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3808
  #2  0x08135ea8 in __sanitizer::internal__exit (exitcode=1)
      at /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/sanitizer_solaris.cc:139

when `__interceptor__exit` tries to call `__interception::real__exit` which
is `NULL` at this point because the interceptors haven't been initialized yet.

Ultimately, the problem lies elsewhere, however: `internal__exit` in
`sanitizer_solaris.cpp` calls `_exit` itself since there doesn't exit a
non-intercepted version in `libc`.  Using the `syscall` interface instead
isn't usually an option on Solaris because that interface isn't stable.
However, in the case of `SYS_exit` it can be used nonetheless: `SYS_exit`
has remained unchanged since at least Solaris 2.5.1 in 1996, and this is
what this patch does.

Tested on `amd64-pc-solaris2.11`.

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

[NFC][FE] Replace TypeSize with StorageUnitSize

On some targets like AIX, last bitfield size is not always equal to last
bitfield type size. Some bitfield like bool will have the same alignment
as [unsigned]. So we'd like to use a more general term `StorageUnit` to
replace type in this field.

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

Reapply "RegAllocFast: Rewrite and improve"

This reverts commit 73a6a164b84a8195defbb8f5eeb6faecfc478ad4.

RegAllocFast: Add extra DBG_VALUE for live out spills

This allows LiveDebugValues to insert the proper DBG_VALUEs in live
out blocks if a spill is inserted before the use of a
register. Previously, this would see the register use as the last
DBG_VALUE, even though the stack slot should be treated as the live
out value.

This avoids an lldb test regression when D52010 is re-applied.

LiveDebugValues: Fix typos and indentation

GlobalISel: Assert if MoreElements uses a non-vector type

[InstCombine] Remove %tmp variable names from bswap-fold tests

Appease update_test_checks script that was complaining about potential %TMP clashes

[FE] Use preferred alignment instead of ABI alignment for complete object when applicable

On some targets, preferred alignment is larger than ABI alignment in some cases. For example,
on AIX we have special power alignment rules which would cause that. Previously, to support
those cases, we added a “PreferredAlignment” field in the `RecordLayout` to store the AIX
special alignment values in “PreferredAlignment” as the community suggested.

However, that patch alone is not enough. There are places in the Clang where `PreferredAlignment`
should have been used instead of ABI-specified alignment. This patch is aimed at fixing those
spots.

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

[mlir][Linalg] Generalize the logic to compute reassociation maps
while folding tensor_reshape op.

While folding reshapes that introduce unit extent dims, the logic to
compute the reassociation maps can be generalized to handle some
corner cases, for example, when the folded shape still has unit-extent
dims but corresponds to folded unit extent dims of the expanded shape.

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

[InstCombine] Add bswap(trunc(bswap(x))) -> trunc(lshr(x, c)) vector tests

Add tests showing failure to correctly fold vector bswap(trunc(bswap(x))) intrinsic patterns

[InstCombine] Fix bswap(trunc(bswap(x))) -> trunc(lshr(x, c)) vector support

Use getScalarSizeInBits not getPrimitiveSizeInBits to determine the shift value at the element level.

[PowerPC] Avoid unused variable warning in Release builds

PPCFrameLowering.cpp:632:8: warning: unused variable 'isAIXABI' [-Wunused-variable]

[PPC] Do not emit extswsli in 32BIT mode when using -mcpu=pwr9

It looks like in some circumstances when compiling with `-mcpu=pwr9` we create an EXTSWSLI node when which causes llc to fail. No such error occurs in pwr8 or lower.

This occurs in 32BIT AIX and BE Linux. the cause seems to be that the default return in combineSHL is to create an EXTSWSLI node.  Adding a check for whether we are in PPC64 before that fixes the issue.

Reviewed By: #powerpc, nemanjai

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

[InstCombine] Add tests for 'partial' bswap patterns

As mentioned on PR47191, if we're bswap'ing some bytes and the zero'ing the remainder we can perform this as a bswap+mask which helps us match 'partial' bswaps as a first step towards folding into a more complex bswap pattern.

[NFC][regalloc] Make VirtRegAuxInfo part of allocator state

All the state of VRAI is allocator-wide, so we can avoid creating it
every time we need it. In addition, the normalization function is
allocator-specific. In a next change, we can simplify that design in
favor of just having it as a virtual member.

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

[DA][SDA] SyncDependenceAnalysis re-write

This patch achieves two things:
1. It breaks up the `join_blocks` interface between the SDA to the DA to
   return two separate sets for divergent loops exits and divergent,
disjoint path joins.
2. It updates the SDA algorithm to run in O(n) time and improves the
   precision on divergent loop exits.

This fixes `https://bugs.llvm.org/show_bug.cgi?id=46372` (by virtue of
the improved `join_blocks` interface) and revealed an imprecise expected
result in the `Analysis/DivergenceAnalysis/AMDGPU/hidden_loopdiverge.ll`
test.

Reviewed By: sameerds

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

[VE] Support TargetBlockAddress

Change to handle TargetBlockAddress and add a regression test for it.

Reviewed By: simoll

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

[ObjCARCAA][NewPM] Add already ported objc-arc-aa to PassRegistry.def

Also add missing AnalysisKey definition.

[mlir][openacc] Remove -allow-unregistred-dialect from ops and invalid tests

Switch to a dummy op in the test dialect so we can remove the -allow-unregistred-dialect
on ops.mlir and invalid.mlir. Change after comment on D88272.

Reviewed By: mehdi_amini

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

[llvm-exegesis] Add option to check the hardware support for a given feature before benchmarking.

This is mostly for the benefit of the LBR latency mode.
Right now, it performs no checking. If this is run on non-supported hardware, it will produce all zeroes for latency.

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

scudo: Make it thread-safe to set some runtime configuration flags.

Move some of the flags previously in Options, as well as the
UseMemoryTagging flag previously in the primary allocator, into an
atomic variable so that it can be updated while other threads are
running. Relaxed accesses are used because we only have the requirement
that the other threads see the new value eventually.

The code is set up so that the variable is generally loaded once per
allocation function call with the exception of some rarely used code
such as error handlers. The flag bits can generally stay in a register
during the execution of the allocation function which means that they
can be branched on with minimal overhead (e.g. TBZ on aarch64).

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

[test][SampleProfile][NewPM] Fix some tests under NPM

[asan][test] Several Posix/unpoison-alternate-stack.cpp fixes

`Posix/unpoison-alternate-stack.cpp` currently `FAIL`s on Solaris/i386.
Some of the problems are generic:

- `clang` warns compiling the testcase:

  compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:83:7: warning: nested designators are a C99 extension [-Wc99-designator]
        .sa_sigaction = signalHandler,
        ^~~~~~~~~~~~~
  compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:84:7: warning: ISO C++ requires field designators to be specified in declaration order; field '_funcptr' will be initialized after field 'sa_flags' [-Wreorder-init-list]
        .sa_flags = SA_SIGINFO | SA_NODEFER | SA_ONSTACK,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  and some more instances.  This can all easily be avoided by initializing
  each field separately.

- The test `SEGV`s in `__asan_memcpy`.  The default Solaris/i386 stack size
  is only 4 kB, while `__asan_memcpy` tries to allocate either 5436
  (32-bit) or 10688 bytes (64-bit) on the stack.  This patch avoids this by
  requiring at least 16 kB stack size.

- Even without `-fsanitize=address` I get an assertion failure:

  Assertion failed: !isOnSignalStack(), file compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp, line 117

  The fundamental problem with this testcase is that `longjmp` from a
  signal handler is highly unportable; XPG7 strongly warns against it and
  it is thus unspecified which stack is used when `longjmp`ing from a
  signal handler running on an alternative stack.

  So I'm `XFAIL`ing this testcase on Solaris.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.

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

[AArch64] Avoid pairing loads when the base reg is modified

When pairing loads, we should check if in between the two loads the
base register has been modified. If that is the case then avoid pairing
them because the second load actually loads from a different address.

Reviewed By: fhahn

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