since that is the normal behaviour of other compilers on the platform.

Reviewed By: hubert.reinterpretcast

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

Summary:
Replace the OpenMP Runtime Library functions used in CGOpenMPRuntimeGPU
for OpenMP device code generation with ones in OMPKinds.def and use
OMPIRBuilder for generating runtime calls. This allows us to consolidate
more OpenMP code generation into the OMPIRBuilder. This patch also
invalidates specifying target architectures with conflicting pointer
sizes.

Reviewers: jdoerfert

Subscribers: aaron.ballman cfe-commits guansong llvm-commits sstefan1 yaxunl

Tags: #OpenMP #Clang #LLVM

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

Summary:
This patch adds an error to Clang that detects if OpenMP offloading is used
between two architectures with incompatible pointer sizes. This ensures that
the data mapping can be done correctly and solves an issue in code generation
generating the wrong size pointer.

Reviewer: jdoerfert

Subscribers:

Tags: #OpenMP #Clang

Differential Revision:

We previously took a shortcut and said that weak variables never have
constant initializers (because those initializers are never correct to
use outside the variable). We now say that weak variables can have
constant initializers, but are never usable in constant expressions.

The current half vector was enforcing an assert expecting
 "(LHS is half vector) == (RHS is half vector)"
for comma.

Reviewed By: ahatanak, fhahn

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

This goes with the APFloat change proposed in
D88238.
This is copied from the MIPS-specific test in
builtin-nan-legacy.c to verify that the normal
behavior is correct on other targets without the
complication of an inverted quiet bit.

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

`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

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

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

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

Also add missing AnalysisKey definition.

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

Reviewed By: simoll

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

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

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

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.

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

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

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

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

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

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

Appease update_test_checks script that was complaining about potential %TMP clashes

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.

This reverts commit 73a6a164.

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

`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

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

Before, for each original argument i, ValNo was set to i + PartIdx, but
ValNo is intended to reflect the index of the value before splitting.
Hence, ValNo should always be set to i and not consider the PartIdx.

Reviewed By: arsenm

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

After removal of Darwin as a PowerPC subtarget, the VRSAVE
save/restore/spill/update code is no longer needed by any supported
subtarget, so remove it while keeping support for vrsave and related instruction
aliases for inline asm. I've pre-commited tests to document the existing vrsave
handling in relation to @llvm.eh.unwind.init and inline asm usage, as
well as a test which shows a beahviour change on AIX related to
returning vector type as we were wrongly emiting VRSAVE_UPDATE on AIX.

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

There doesn't seem to be any good reason for having a separate path for when we bswap/bitreverse at a smaller size than the destination size - so merge these to make the instruction generation a lot clearer.

Appease update_test_checks script that was complaining about potential %TMP clashes

Now that VPUser is not inheriting from VPValue, we can take the next
step and turn the recipes that already manage their operands via VPUser
into VPUsers directly. This is another small step towards traversing
def-use chains in VPlan.

This is NFC with respect to the generated code, but makes the interface
more powerful.

Add a missing include and some definitions in 76953321.

Patch by: Brooks Davis

Reviewed by: labath

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