Currently the GPU build requires the `LLVM_LIBC_FULL_BUILD` option to be
set. This patch changes the logic so that it is always enabled when
targeting the GPU. Also, this patch allows `LIBC_GPU_BUILD` and
`LIBC_GPU_ARCHITECTURES` to both enable a GPU build. Now, enabling the
GPU support should only require the following CMake:

```
  -DLLVM_ENABLE_RUNTIMES=libc -DLIBC_GPU_ARCHITECTURES=gfx1030
```

Reviewed By: jdoerfert, sivachandra

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

The 2>&1 moving part is similar to commit 731264b0.

Original commit message:
I recently added a check to make sure the lower 2 bits of the opcode
were 0x3. A post commit comment pointed out this would be allowed
for a custom extension when C is not supported.

Note, binutils does have this restriction.

Reviewed By: rriddle

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

Lower to calling __sync_lock_test_and_set_* for target < M68020.

This reverts commit 4fde20b8.

I failed to squash this

This reverts commit 5c5fe3af.

This is failing on the build bots

This reverts commit 5e2445ae.

This is failing on the build bots.

The motivating example is in https://godbolt.org/z/45nbdYMK9
- For this example, `subs` is generated for the good case; `sub` followed by `cmp` is generated for the bad case. Since signed overflow is undefined behavior in C/C++ (indicated as `nsw` flag in LLVM IR), `subs` should be generated for the good case as well.

This patch relaxes one restriction from "quit optimization when V is used" to "continue if MI produces poison value when signed overflow occurs". This is not meant to be C/C++ specific since it looks at 'NoSWrap' since it looks at MachineInstr flags.

Reviewed By: dmgreen

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

Pre-commit test cases to show missed icmp-opt with flag-setting ALUs

Reviewed By: dmgreen

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

Members in an scc are supposed to be sorted in a top-down or topological order based on edge weights. Previously this is achived by building a MST out of the SCC and enforcing an BFS walk on the MST. A BFS on a tree does give a top-down topological order, however, the MST built here isn't really a tree. This is becuase of a trick done to avoid expansive detection of a cycle on a directed graph when an edge is added. When the MST is built, its edges are considered undirected. But in reality they are directed, thus a BST walk doesn't necessarily give a topological order. I'm tweaking the BFS walk slightly to yield a topological order.

Basically I'm using Kahn's algorithm on MST to compute a topological traversal order. The algorithm starts from nodes that have no incoming edge. These nodes are "roots" of the MST forest. This ensures that nodes are visited before their descendants are, thus ensures a topological traversal order of the MST.

Reviewed By: wenlei

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

We've supported .insn for non-compressed for a while. This finishes the compressed supported.

Reviewed By: asb

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

I recently added a check to make sure the lower 2 bits of the opcode
were 0x3. A post commit comment pointed out this would be allowed
for a custom extension when C is not supported.

Note, binutils does have this restriction.

Add some special cases for UADDO to recover codegen after D146786.

Reviewed By: reames, liaolucy

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

For add, if we match the constant edge case the add isn't used by
the compare so we shouldn't check for 2 users.

For sub, the compare is not a user of the sub so the math is
used if the sub has any users.

This regresses RISC-V which I will work on other patches for.

Reviewed By: RKSimon

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

Drop the trailing j function signature artifact.

add a test to check for gep vectorization after the change from D144128 where the gep vectorization is dependant on the target hook `prefersVectorizedAddressing()`

Reviewed By: fhahn

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

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

D146449 already updated comments. Strings may have more user impact.

Reviewed By: asb

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

To be consistent with RISC-V branding guidelines
https://riscv.org/about/risc-v-branding-guidelines/
Think we should be using RISC-V where possible.

More patches will follow.

Reviewed By: asb

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

Add common CHECK prefix

Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.

This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.

This is in essence a revert of 2659663e, but since then the test suite
has changed significantly. Back when I did 2659663e,...

This is already implied, but let's just be explicit about it.

Reviewed By: MaskRay

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

The linker wrapper needs to reinvent its own special static library
handling for static libraries containing fatbinaries. This is primarily
because offloading languages expect certain global symbols to be visible
to the host so we must consider them used symbols. However we should be
able to remove this requirement if we are linking in "freestanding" code
that was not created by an offloading language.

The motivation for this is to support the work-in-progress `libc` for
GPUs. It is provided as a static library with no offloading language
set. This logic will let us only import used `libc` symbols always.

Reviewed By: yaxunl

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

Add common CHECK prefix, and rename X32 -> X86 (we try to use X32 for gnux32 triples)

Use CRTP to enable creating statically dispatched subclasses of
ExtractAPIVisitor.
This enables adding extension points and customising the behavior more
easily.

This is used in CXExtractAPI.cpp to create a specialized visitor for
Libclang as well as streamlining the batch implementation in ExtractAPIConsumer.cpp

[clang][ExtractAPI] Improve tests for clang_getSymbolGraphForCursor

Adds a new mode to c-index-test that can fetch a single symbol symbol
graph for a given source location. This way we can be more precise when
writing tests for clang_getSymbolGraphForCursor.
Additionaly this makes it easier to debug the function.

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

Use CRTP to enable creating statically dispatched subclasses of
ExtractAPIVisitor.
This enables adding extension points and customising the behavior more
easily.

This is used in CXExtractAPI.cpp to create a specialized visitor for
Libclang as well as streamlining the batch implementation in ExtractAPIConsumer.cpp

The current dialect conversion does not support 1:N type conversions.
This commit implements a (poor-man's) dialect conversion pass that does
just that. To keep the pass independent of the "real" dialect conversion
infrastructure, it provides a specialization of the TypeConverter class
that allows for N:1 target materializations, a specialization of the
RewritePattern and PatternRewriter classes that automatically add
appropriate unrealized casts supporting 1:N type conversions and provide
converted operands for implementing subclasses, and a conversion driver
that applies the provided patterns and replaces the unrealized casts
that haven't folded away with user-provided materializations.

The current pass is powerful enough to express many existing manual
solutions for 1:N type conversions or extend transforms that previously
didn't support them, out of which this patch implements call graph type
decomposition (which is currently implemented with a Va...

This patch teaches computeKnownBitsForTargetNode about MUL_IMM.

MUL_IMM comes up in certain select of constants.  Specifically, it is
used to multiply the result of SETCC.  Computing the known zero bits
of MUL_IMM allows matchAddressRecursively us to convert some OR into
ADD, which eventually becomes a part of LEA.

This patch fixes:

https://github.com/llvm/llvm-project/issues/61365

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

When a typedef node is imported, ASTImporter should not find an existing similar
typedef node for it that comes from different context (translation unit or scope).
This should avoid a situation where an existing typedef declaration is returned
at import of a typedef, but the underlying type was already imported as a new
type object.

Reviewed By: vabridgers

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

The plan is to merge most of the functionality of both of these into a single 'match vector sized data' function.

The -mxcoff-build-id=0xHEXSTRING option is an alternative to the
--build-id=0xHEXSTRING linker option that is not currently available in
the AIX linker.

If HEXSTRING is an odd number of hex digits then a '0' character is prepended.
The characters ':' and '-' are not allowed (unlike the GNU linker option).
The given build-id will be saved in the string table of the loader section.

A subsequent commit will teach the profile runtime to read and use the embedded id.

Reviewed By: daltenty, qiongsiwu1, stephenpeckham

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

currently in can_use_perfcounters() in
llvm/test/tools/llvm-exegesis/lit.local.cfg, we check if we can execute
llvm-exegesis. But we don't check if we did actually find llvm-exegesis. If we
didn't, lit.util.which() will return None, and we try to execute that.

Reviewed By: courbet

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

When type conversion fails, return pattern failure instead of crashing.

Closes #61717.

This happened on a small number of MSVC releases (19.31.31xxx, Visual Studio 2022 17.1.x), and worked fine on everything else.

The issue seemed to be related to return type deduction on a function with and `if constexpr`; the compiler got confused and deduced different function return type from the type of the return statement.

The workaround is to split `get` into two functions using `enable_if`.

Reviewed By: dstuttard

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

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

Qualifiers were not moved for non-pointer non-simple types.
Add additional support for many special cases such as templates,
requires clauses, long qualified names.

Fixes https://github.com/llvm/llvm-project/issues/57154 and
https://github.com/llvm/llvm-project/issues/60898

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

As far as I can tell, the instruction flags set in the various
RISCVInstrInfo*.td files are always under-approximations. That is,
something like isTerminator will only be set for opcodes that are
*always* terminators.

The exception seems to be isCall; this is set for JAL/JALR while these
instruction are not always calls. This patch proposes to remove isCall
from JAL/JALR for consistency.

A follow-up patch will add more detailed analysis of some instruction
properties based on MCInstrAnalysis.

Reviewed By: asb, craig.topper

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