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

If we use tail-folding for reverse loops that contain loads
and stores then we will need to reverse the loop predicate.
This patch adds a new 'reverse' sve-tail-folding option and
ensures they are not considered 'simple'.

I did this by adding a function called
containsDecreasingPointers to AArch64TargetTransformInfo.cpp
that searches all instructions in the loop for loads or
stores with negative strides.

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

We do not currently have this written down anywhere, and as a result,
we're sometimes inconsistent with how we handle feature test macros and
the feature status pages. This is an attempt to document what I
understand our existing policies to be instead of defining a new policy.

Note, this is being added to the Clang internals manual because we
don't have a separate document for Clang developer policies. At some
point, I think we may want a standalone document for that, and this
content can be moved there at that time.

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

ConcurrentHashTable - is a resizeable concurrent hashtable.
The range of resizings is limited up to x2^31.
The hashtable allows only concurrent insertions.

Concurrent hashtable is necessary for the D96035 patch.

Reviewed By: JDevlieghere

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

The current behaviour of always writing the unqualified form of an attribute or type is problematic for any type or attribute that might output an empty string, making it impossible to parse and therefore roundtrip. This is commonly the case for any types or attributes with optional parameters. One would have to currently woarkaround the issue by either changing ones syntax to not be completetly empty or by explicitly using `qualified` in ALL ops using that type or attribute.

This patch fixes that issue by simply checking whether anything was written to the output. In the case there wasn't, it simply falls back to using the normal printer with the dialect prefix. This also makes the default of unqualified printing always correct and safe. The implementation could theoretically still be tricked if the user were to print just a space or similar. I'd argue this'd be user error and not worth handling.

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

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

This patch adds the necessary build infrastructure to build and run the
integration tests on NVIDIA GPUs. The NVIDIA `nvlink` linker utility is
what is ultimately used to combine these files into a single executable
image. Unfortunately, their tool does not support static libraries. So
we need to link with every object directly instead. This could be solved
by impelementing a "wrapper" utility around `nvlink` like we used to use
for OpenMP. But for now this should be sufficient.

Reviewed By: sivachandra

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

Prior to this patch, UpperBound refered to the largest LMUL
supported. Instructions used UpperBound to assign the worst
case behaviour to records, since Instructions are not LMUL
specific. This forced the largest LMUL to have the worst case
behavior, even if that wasn't true for a subtarget.

Now that SchedWrites, SchedReads, WriteRes, and ReadAdvances
are created for (name, LMUL) pairs and (name, LMUL, SEW)
tuples, it becomes even less clear which pair should correspond
to the worst case behavior. Additionally, it no longer makes sense
for the UpperBound to belong to LMUL list and not to the SEW list.

Instead of creating a special UpperBound LMUL and an UpperBound
SEW, this patch renames UpperBound to WorstCaseBehavior, removes
it from the SchedMxList, and defines a WorstCaseBehavior SchedWrite,
SchedRead, WriteRes, and ReadAdvance for each name.

This gives subtargets the ability to describe the worst case behavior
of a record without forcing it to be the largest LMUL or the smallest
SEW.

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

This reverts commit 74c0bd24.

This patch adds the initial support for vector functions and register banks
within GlobalISel. With this patch, we are able to support simple functions that
return vectors, and also functions that perform simple operations.

This patch also:
- Legalizes vector types for G_AND, G_OR, G_XOR, G_ADD, G_SUB, G_BITCAST, G_FADD, G_FSUB
- Introduce initial support for bitcasting (that will need to be extended upon)
- Add various different test cases to for test vector support within GlobalISel

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

[PowerPC] Implement 64-bit ELFv2 Calling Convention in TableGen (for integers/floats/vectors in registers)

This patch partially implements the parameter passing rules outlined in the
ELFv2 ABI within TableGen. Specifically, it implements the parameter assignment
of integers, floats, and vectors within registers - where the GPR numbering will
be "skipped" depending on the ordering of floats and vectors that appear within
a parameter list.

As we begin to adopt GlobalISel to the PowerPC backend, there is a need for a
TableGen definition that encapsulates the ELFv2 parameter passing rules. Thus,
this patch also changes the default calling convention that is returned within
the ccAssignFnForCall() function used in our GlobalISel implementation, and also
adds some additional testing of the calling convention that is implemented.

Future patches that build on top of this initial TableGen definition will aim to
add more of the ABI complexities, including support for additional types and
also in-memory arguments.

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

I don't think these are holding their weight and cause nasty to debug
compiler issues with some versions of MSVC as seen in
https://reviews.llvm.org/D144083#4220866

Just qualify the types with the full name.

Prior to this patch, UpperBound refered to the largest LMUL
supported. Instructions used UpperBound to assign the worst
case behaviour to records, since Instructions are not LMUL
specific. This forced the largest LMUL to have the worst case
behavior, even if that wasn't true for a subtarget.

Now that SchedWrites, SchedReads, WriteRes, and ReadAdvances
are created for (name, LMUL) pairs and (name, LMUL, SEW)
tuples, it becomes even less clear which pair should correspond
to the worst case behavior. Additionally, it no longer makes sense
for the UpperBound to belong to LMUL list and not to the SEW list.

Instead of creating a special UpperBound LMUL and an UpperBound
SEW, this patch renames UpperBound to WorstCaseBehavior, removes
it from the SchedMxList, and defines a WorstCaseBehavior SchedWrite,
SchedRead, WriteRes, and ReadAdvance for each name.

This gives subtargets the ability to describe the worst case behavior
of a record without forcing it to be the largest LMUL or the smallest
SEW.

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

This reverts commit c6e98237.

Reason: Broke the ASan buildbots, see https://reviews.llvm.org/D126959
(the original phabricator review) for more info.