Created using spr 1.3.4

Pseudo Mnemonic could be of other uses.

This patch adds SWIG cmake flags to the stage2 build in Fuchsia
Clang configuration.

Summary:
The RPC server build for the GPU support needs to be build from the
"projects" phase of the LLVM build. That means it is built with the same
compile that LLVM supports, which currently is GCC 7.4 in most cases.
A previous patch removed the `LIBC_HAS_BUILTIN` indirection we used,
which regressed the case where we used the `libc` source externally. The
files that we need to use here are `converter.cpp` and `writer.cpp`
which currently are compatible with C++17, so there aren't issues with
the code itself. However, older GCC does not have this builtin which
makes the checks fail.

This patch just adds in a simple wrapper that allows it to correctly
ignore everything if using a compiler that doesn't support it.

Fixes #86559.

Summary:
This patch adds an implementation of `printf` that's provided by the GPU
C library runtime. This `pritnf` currently implemented using the same
wrapper handling that OpenMP sets up. This will be removed once we have
proper varargs support.

This `printf` differs from the one CUDA offers in that it is synchronous
and uses a finite size. Additionally we support pretty much every format
specifier except the `%n` option.

Depends on https://github.com/llvm/llvm-project/pull/85331

This adds support for `GNU_PROPERTY_AARCH64_FEATURE_PAUTH` feature (as
defined in https://github.com/ARM-software/abi-aa/pull/240) handling in
llvm-readobj and llvm-readelf. The following constants for supported
platforms are also introduced:

- `AARCH64_PAUTH_PLATFORM_INVALID = 0x0`
- `AARCH64_PAUTH_PLATFORM_BAREMETAL = 0x1`
- `AARCH64_PAUTH_PLATFORM_LLVM_LINUX = 0x10000002`

For the llvm_linux platform, output of the tools contains descriptions
of PAuth features which are enabled/disabled depending on the version
value. Version value bits correspond to the following `LangOptions`
defined in #85232:

- bit 0: `PointerAuthIntrinsics`;
- bit 1: `PointerAuthCalls`;
- bit 2: `PointerAuthReturns`;
- bit 3: `PointerAuthAuthTraps`;
- bit 4: `PointerAuthVTPtrAddressDiscrimination`;
- bit 5: `PointerAuthVTPtrTypeDiscrimination`;
- bit 6: `PointerAuthInitFini`.

Support for `.note.AARCH64-PAUTH-ABI-tag` is dropped since it's deleted
from the spec in ARM-software/abi-aa#250.

Summary:
This patch adds a temporary implementation that uses a struct-based
interface in lieu of varargs support. Once varargs support exists we
will move this implementation to the "real" printf implementation.

Conceptually, this patch has the client copy over its format string and
arguments to the server. The server will then scan the format string
searching for any specifiers that are actually a string. If it is a
string then we will send the pointer back to the server to tell it to
copy it back. This copied value will then replace the pointer when the
final formatting is done.

This will require a built-in extension to the varargs support to get
access to the underlying struct. The varargs used on the GPU will simply
be a struct wrapped in a varargs ABI.

When a nested parallel region ends, the runtime calls __kmp_join_call().
During this call, the primary thread of the nested parallel region will
reset its tid (retval of omp_get_thread_num()) to what it was in the
outer parallel region. A data race occurs with the current code when
another worker thread from the nested inner parallel region tries to
steal tasks from the primary thread's task deque. The worker thread
reads the tid value directly from the primary thread's data structure
and may read the wrong value.

This change just uses the calculated victim_tid from execute_tasks()
directly in the steal_task() routine rather than reading tid from the
data structure.

Fixes: #87307

This fixes a test broken in 3d469c0e.
fast-forwarded.
../clang/test/CodeGenHLSL/builtins/wave_get_lane_index_subcall.hlsl

We can't just check if it is a splat constant or not. We should also
check if the value match.

Make sure that VPInstructions with OR opcodes are properly registered as
disjoint ops.

Fixes https://github.com/llvm/llvm-project/issues/87378.

We only use the `RM` equivalents now.

This allows us to use the less privileged pull_request event for the
validate_email job, since this workflow no longer writes a comment
directly.

This paper added a pile of macros for atomic initialization which we
started supporting in Clang 4.0.

Summary:
There are other dependencies to enable `unistd.h` on the GPU which
prevented the header from being generated. This is a POSIX extension and
isn't part of the core `libc`, so we can just disable this for now to
get the bots gree.

Explicitly added gfx940, which has SC and NT bits. There must be better
ways of documenting the cache policy. But this is what I can do now.

Fixes: SWDEV-449810

CallSiteInfo is originally used only for argument - register pairs. Make
it struct, in which we can store additional data for call sites.

Also, the variables/methods used for CallSiteInfo are named for its
original use case, e.g., CallFwdRegsInfo. Refactor these for the
upcoming
use, e.g. addCallArgsForwardingRegs() -> addCallSiteInfo().

An upcoming patch will add type ids for indirect calls to propogate them
from
middle-end to the back-end. The type ids will be then used to emit the
call
graph section.

Original RFC:
https://lists.llvm.org/pipermail/llvm-dev/2021-June/151044.html
Updated RFC:
https://lists.llvm.org/pipermail/llvm-dev/2021-July/151739.html

Differential Revision: https://reviews.llvm.org/D107109?id=362888



Co-authored-by: Necip Fazil Yildiran <necip@google.com>

Fixes #85400

This adds an option to break function definition parameters, putting
them on the next line after the function's opening paren.

This was a missing step towards allowing styles which require all
function definition parameters be on their own lines.

Closes #62963

If the odd vector is undef or poison, the widening add and multiply trick
doesn't work unless we freeze the odd vector.

Unfortunately, freezing doesn't work when the operand is provably
undef/poison. MIR doesn't have a representation for freeze so it
just becomes a COPY from IMPLICIT_DEF which freely propagates undef
to each operand independently.

To work around this, check for undef explicitly and lower to a VZEXT_VL
of the even vector. This produces better code than we'd get from a
freeze anyway.

I've left a FIXME for adding a freeze. I'll do that as a separate patch
as it affects other tests and doesn't help with the new test.

The interleave lowering relies on a math trick that requires passing
the odd vector to two math instructions. In order to be correct
these instructions must see the same value.

If the odd vector is provably poison or undef, SelectionDAG will
create a vwadd and vwmaccu where the operand is a copy from IMPLICIT_DEF.
Later this will become just the undef flag on the operand. This
gives the register allocator freedom to pick a different register
for each instruction.

If we have mixed extractelement instructions, fixed and scalable ones,
need to check that compiler tries to estimate the cost for fixed vector
extractelement, not the scalable one, to avoid compiler crash.

Fixes  #86506

Fixes #85578, a use-after-free caused by some `MCSymbolWasm` data being
freed too early.

Previously, `WebAssemblyAsmParser` owned the data that is moved to
`MCContext` by this PR, which caused problems when handling module ASM,
because the ASM parser was destroyed after parsing the module ASM, but
the symbols persisted.

The added test passes locally with an LLVM build with AddressSanitizer
enabled.

Implementation notes:

* I've called the added method
<code>allocate<b><i>Generic</i></b>String</code> and added the second
paragraph of its documentation to maybe guide people a bit on when to
use this method (based on my (limited) understanding of the `MCContext`
class). We could also just call it `allocateString` and remove that
second paragraph.
* The added `createWasmSignature` method does not support taking the
return and parameter types as arguments: Specifying them afterwards is
barely any longer and prevents them from being accidentally specified in
the wrong order.
* This removes a _"TODO: Do the uniquing of Signatures here instead of
ObjectFileWriter?"_ since the field it's attached to is also removed.
Let me know if you think that TODO should be preserved somewhere.

Correct strictfp tests to follow the rules documented in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

These tests needed the strictfp attribute added to some function
definitions.

Test changes verified with D146845.

This option was added so that changing CMake GCC_INSTALL_PREFIX would
not cause test failures or due to cargo culting. Setting
GCC_INSTALL_PREFIX leads to an error now and we should stop making our
tests ugly.

VPERMI (VPERMQ/PD) is nearly always lane-crossing and poorly merges with target shuffles (other than itself).

For now, I've restricted VPERMI to only merge with itself, constants, loads and splats.

We might be able to merge with a few other special cases (AND/ANDNP with constant?), which could help the shuffle-vs-trunc-256.ll AVX512VL regression, but since that now gives similar codegen to the other AVX512 variants, I'd prefer to improve the shuffle lowering for that properly.

Fixes  #87126.

This moves the definition of a `pair` constructor for `<tuple>` to
`<__utility/pair.h>` and uses the forward declaration of `pair` in
`<tuple>` instead of including the definition.

C89 has more restrictions on aggregate initialization that were relaxed
in C99. We started diagnosing the C89 extension in Clang 3.4.

I can't locate a document number for this particular change, but C89
had the following entry in Future Language Directions:

The use of two parameters declared with an array type (prior to their
adjustment to pointer type) in separate lvalues to designate the same
object is an obsolescent feature.

C99 removed this entry. Clang and LLVM have never done anything in
support of that deprecation, so we trivially conform to its removal.

We previously marked this as "No" but that's confusing; Annex H doesn't
require any changes for a C implementation, it's about how C relates to
other standards. We could mark this N/A, but I think it makes more
sense to treat it like a runtime library-specific change and simply
remove it from the tracker entirely.

- Factor out a shouldCastToInt() method.
- Also pass through pointer type values to not be casted to integer.

CC @uweigand