[LinkerWrapper] Do not extract globals with no offloading language

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

[X86] Regenerate avx2-shift.ll check prefixes

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

[gn build] Port ea35740e7e18

Address code review feedback

[clang][ExtractAPI] Refactor ExtractAPIVisitor to make it more extensible

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

[clang][ExtractAPI] Refactor ExtractAPIVisitor to make it more extensible

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

[mlir] Implement pass utils for 1:N type conversions.

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 ValueDecomposer
that is only used there).

The goal of this pass is to illustrate the effect that 1:N type
conversions could have, gain experience in how patterns should be
written that achieve that effect, and get feedback on how the APIs of
the dialect conversion should be extended or changed to support such
patterns. The hope is that the "real" dialect conversion eventually
supports such patterns, at which point, this pass could be removed
again.

Reviewed By: springerm

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

[X86] Teach computeKnownBitsForTargetNode about MUL_IMM

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

[clang][ASTImporter] Import typedefs to distinct records as distinct nodes.

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

[X86] Move combineVectorSizedSetCCEquality above MatchVectorAllZeroTest. NFC.

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

[AIX][Driver] Implement -mxcoff-build-id option

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

[llvm-exegesis] if lit can't find llvm-exegesis, fail gracefully

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

[mlir] FuncToLLVM: fail gracefully in bare pointer multi-result covnersion

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

Closes #61717.

[ADT] Work around MSVC bug affecting `get(enumerator_result)`

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

[clangd] Use expansion location for missing include diagnostics.

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

[clang-format] Improve QualifierAlignment

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

[RISCV] Remove isCall instruction flag from JAL/JALR

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

[SVE][LoopVectorize] Add option to disable tail-folding for reverse loops

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

[gn build] Port 42058eea7912

Document the Clang policies on claiming support for a feature

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

[reland][ADT] add ConcurrentHashtable class.

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

[mlir][AsmPrinter] Fallback to using qualified printer if unqualified output is empty

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

[libc] Enable integration tests targeting NVIDIA GPUs

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

[RISCV] Remove UpperBound from SchedMxList and create WorstCaseBehavior records

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

[MC] Quick fix for Windows build failures after D142218

Revert "[RISCV] Remove UpperBound from SchedMxList and create WorstCaseBehavior records"

This reverts commit 74c0bd240499683078d4f15d31de690950da8231.

[PowerPC][GISel] Add initial GlobalISel support for vector functions.

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

[JITLink] Drop using namespace

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.

[RISCV] Remove UpperBound from SchedMxList and create WorstCaseBehavior records

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

Revert "[C++20][Modules] Introduce an implementation module."

This reverts commit c6e9823724ef6bdfee262289ee34d162db436af0.

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

Revert "Silence unused variable warning in NDEBUG builds"

This reverts commit 8c7c1f11ffaacf762e612c65440fd2cbb58ee426.

Reason: Dependent change https://reviews.llvm.org/D126959 broke the ASan
buildbots. See that phabricator review for more comments.

[llvm-exegesis] Improve test flexibility by using available_features

Currently, all llvm-exegesis regression tests are target-specific and
they are organized so that the entire subdirectories of
llvm/test/tools/llvm-exegesis are enabled or disabled as a whole.

After the commit e0ad2af691 ("Skip codegen" dry-run mode), at least two
kinds of tests are possible:
1) ensure that a snippet can be *generated* for the particular opcode
2) tests involving actual snippet execution inside the llvm-exegesis
   process

Thus, for the particular target subdirectory, some tests should run only
on the particular host architecture and other tests only need the target
being among LLVM_TARGETS_TO_BUILD.

This commit defines a bunch of exegesis-specific features that can be
referenced in REQUIRES, UNSUPPORTED, etc. on a test-by-test basis.

~~

Huawei RRI

Reviewed By: courbet

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

Add Release Note for -mcode-object-v3 removal

Reviewed By: aaron.ballman

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

[Flang][OpenMP] Added TODO checks for unsupported map types

This patch adds TODO checks for unspported types in the map clause for OpenMP Target directives.

Example of unsupported code:

implicit none
character(len=10) :: str1, str2(5,5)

type t
  character(len=10) :: str1, str2(5,5)
end type t
type(t) :: v

!$omp target enter data map(to: str2(2,5))
!$omp target enter data map(to: v%str1)
!$omp target enter data map(to: v%str2)
!$omp target enter data map(to: v%str2(1,2))

end

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

[TableGen][GlobalISel] Support EXTRACT_SUBREGs for ComplexPattern suboperands.

This makes it possible to write GlobalISel patterns generating
EXTRACT_SUBREG instructions applied to suboperands of ComplexPattern
operands. Currently, TableGen complains that such operands are not
declared in matcher.

Reviewed By: arsenm

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

[mlir][ClangTidy] Remove redundant return (NFC).

[MLIR][LLVM] Extend argument/result/function attribute support.

Use a disallowlist approach to deselect attributes on arguments and
return values that are not yet supported, but allow the rest to be
present when inlining.

To achieve fast lookup in `isLegalToInline`, the set of unsupported
function attributes is cached on the inliner interface object during
construction. By using a set of StringAttrs this should just amount to a
pointer lookup.

Depends on D146633

Reviewed By: gysit

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

[mlir][Linalg] NFC - Move transform utilities related to subcomputation inference to Linalg/Utils

[MC] Store operand info immediately after the TargetInsts table. NFC.

This shrinks MCInstrDesc (and hence the whole TargetInsts table) because
we can store a 16-bit offset value to access the operands info, instead
of a pointer. This also reduces the number of relocs that need to be
applied when LLVM is compiled as position-independent code.

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

[MC] Store implicit ops immediately after the TargetInsts table. NFC.

This shrinks MCInstrDesc (and hence the whole TargetInsts table) because
we can store a 16-bit offset value to access the implicit operands,
instead of a pointer. This also reduces the number of relocs that need
to be applied when LLVM is compiled as position-independent code.

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

[clang] source range of variable template specialization should include initializer

This patch adjust the getSourceRange() for the
VarTemplateSpecializationDecl and VarTemplatePartialSpecializationDecl,
such that the initializer is included if present:
```
template<typename T>
T temp = 1;

template<> double temp<double> = 1;
```
This patch makes it consistent with the behavior of
non-template variables with initializers and restores
behavior that was present before https://reviews.llvm.org/D139705.

n case, when the initializer is not present we still
include the template arguments in the source range,
which was required for fixing zero-initialization fix-it.

Reviewed By: erichkeane

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

[AMDGPU] Remove `use-legacy-divergence-analysis`

This option has been a no-op since we switched to UA.

Reviewed By: foad

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

Revert "[mlir] Implement pass utils for 1:N type conversions."

This reverts commit 9c4611f9c7a7055b18f0a30a4c9074b9917e4ab0.

[LV][ARM][AArch64] Add multi-exit Loop Vectorizer tests. NFC

These are useful to test with the various predication schemes available on
different targets.

[documentation] Fix Typos

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

Patch By: ipriyanshi1708

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

[mlir] Implement pass utils for 1:N type conversions.

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 ValueDecomposer
that is only used there).

The goal of this pass is to illustrate the effect that 1:N type
conversions could have, gain experience in how patterns should be
written that achieve that effect, and get feedback on how the APIs of
the dialect conversion should be extended or changed to support such
patterns. The hope is that the "real" dialect conversion eventually
supports such patterns, at which point, this pass could be removed
again.

Reviewed By: springerm

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

[LoopVectorize] Don't tail-fold for scalable VFs when there is no scalar tail

Currently in LoopVectorize we avoid tail-folding if we can
prove the trip count is always a multiple of the maximum
fixed-width VF. This works because we know the vectoriser
only ever chooses a VF that is a power of 2. However, if
we are also considering scalable VFs then we conservatively
bail out of the optimisation because we don't know the value
of vscale, which could be an odd or prime number, etc.

This patch tries to enable the same optimisation for scalable
VFs by asking if vscale is known to be a power of 2. If so,
we can then query the maximum value of vscale and use the same
logic as we do for fixed-width VFs. I've also added a new TTI
hook called isVScaleKnownToBeAPowerOfTwo that does the same
thing as the existing TargetLowering hook.

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

[Docs][llvm-exegesis] Refactor snippet annotations in documentation

Currently, the llvm-exegesis documentation page has all
snippet annotation information under an example. This patch refactors
the annotation documentation to a separate section to make things more
clear and to make adding future annotations easier. This patch also
significantly expands the documentation on the memory scratch space to
which a pointer can be passed through a register as the documentation on
this was quite sparse previously.

Reviewed By: courbet

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

[llvm-exegesis] Refactor InstructionBenchmark to Benchmark

When llvm-exegesis was first introduced, it only supported benchmarking
individual instructions, hence the name for the data structure storing
the data corresponding to a benchmark being called InstructionBenchmark
made sense. However, now that benchmarking arbitrary snippets is
supported, InstructionBenchmark doesn't correspond to a single
instruction. This patch refactors InstructionBenchmark to be called
Benchmark to clean up this little bit of technical debt.

Reviewed By: courbet

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

[clang] Test for AST Dumping of the template variables

They illustrate unstable behavior of the https://reviews.llvm.org/D139705 after serialization.
(`#61680 <https://github.com/llvm/llvm-project/issues/61680>`).

Reviewed By: aaron.ballman

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

[AMDGPU][printf] Run AMDGPUPrintfRuntimeBindingPass in -O0

AMDGPUPrintfRuntimeBindingPass is not run in the IR optimization
pipeline with -O0.

This means that with OpenCL the printf definition coming from
device_libs gets linked with the user's code, which blocks
AMDGPUPrintfRuntimeBindingPass from working after the linkage is done.

Reviewed By: arsenm

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

[clang] Remove legacy -m(no)-code-object-v3 options

Code object V2 and V3 have been deprecated for a long time.
They're now scheduled to be removed completely from LLVM in the coming weeks/months.

There is no reason to support those legacy options anymore as they've
also been deprecated for a long time.

Reviewed By: #amdgpu, yaxunl, artem.tamazov

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

[dataflow] Delete legacy aliases

I can't find any trace of use anymore.
I'm not sure renaming the header is worth the break, but leave the FIXME.

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

[mlir][bufferize] Fix tracking of erased ops

This is a workaround until D144193 has landed.

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

[Target] Use isNullConstant (NFC)

[RISCV] Support vector type strict_fsqrt.

Reviewed By: craig.topper

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

[Target] Use isAllOnesConstant (NFC)

[AArch64][CodeGen] Add few more tests for fused operations (NFC)

Add more tests to show oppurtunity for generating fused mul+add/sub ops.

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

[LLJIT] Allow multiple loadPlatformDynamicLibrary calls with the same path.

Where the same dylib is loaded more than once we should just return the
JITDylib created by the first call rather than error out. This matches the
behavior of dlopen / LoadLibrary.

[Driver][NetBSD] Simplify NetBSD version handling

NetBSD 6.x and older is ancient. Remove now unnecessary version check.

Reviewed By: mgorny

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

[RISCV] Allow llvm-objdump to disassemble objects with unrecognised versions of known extensions

This Moves ELFObjectFile to using
RISCVISAInfo::parseNormalizedArchString which is not an NFC, as the test
changes show. D144353 transitioned LLD to using this function, which is
specialised to parsing arch strings in the normalised format specified
in the psABI rather than user-authored strings accepted in `-march`,
which has greater flexibility.

parseNormalizedArchString does not ignore or produce an error for ISA
extensions with a version that isn't recognised/supported by LLVM. As
current GCC is marking its objects with a higher version of the A, F,
and D extensions than LLVM (see [extension versioning
discussion](https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472)
this massively improves the usability of llvm-objdump with such
binaries.

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

[RISCV] Enable tools such as llvm-objdump to process objects with unrecognised base ISA versions

Tools such as llvm-objdump will currently inputs when the base ISA has
an unrecognised version. I addressed a similar issue in LLD in D144353,
introducing parseArchStringNormalized. While it would make sense to
migrate `llvm/lib/Object/ELFObjectFile.cpp` to using
`parseArchStringNormalized` as well, this patch takes a less ambitious
initial step. By tweaking the behaviour of `parseArchString` when
`IgnoreUnknown` is true (which only has one in-tree user), we use the
default supported ISA version when a base ISA with unrecognised version
is encountered.

This means that llvm-objdump and related tools will function better for
objects produced from a recent GCC. This isn't a full fix, as
IgnoreUnknown means that an imafd object with attributes specifying
newer A/F/D versions will have those extensions ignored.

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

[TableGen] Format document

Add missing bang operators and reorder them in alphabetical order.

Reviewed By: craig.topper

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

[clangd] Fix a hover crash on unsigned 64bit value

This patch adapts to D140059, which makes an assumption that the
caller of `APSInt::getExtValue` promises no narrowing conversion
happens, i.e., from unsigned int64 to signed int64.

It also fixes clangd/clangd#1557.

Reviewed By: nridge

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

[X86][NFC]Remove dead code in X86ISelLowering.cpp

Look at the code in X86ISelLowering.cpp line 15579, when NumV2Elements == 0,
it has been handled in that scope, and will not move to the line 15612.

Reviewed By: RKSimon

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

[LLJIT] Add convenience methods for loading dylibs and linking static libs.

LLJIT::loadPlatformDynamicLibrary loads a dynamic library at a given path
(interpreted in the executor process -- the process containing the JIT'd code),
and returns a JITDylib (whose name is the given path) that reflects the symbols
in that library. LLJIT clients wishing to make the given symbols visible to
their JIT'd code can add this JITDylib to the link order of their JITDylib(s)
using JITDylib::addToLinkOrder.

The LLJIT::linkStaticLibraryInto overloads load a static library (or universal
binary) at a given path (interpreted in the controller process -- the process
containing the LLJIT instance) and adds its symbols to the given JITDylib.

The lli tool is updated to use LLJIT::linkStaticLibraryInto to implement the
extra-archive option.

LLJIT::loadPlatformDynamicLibrary is not tested in this patch as we don't have
a good way to produce dylibs in LLVM's regression test suite.

[clang-format] Don't squash Verilog escaped identifiers

An escaped identifier always needs a space following it so the parser
can tell it apart from the next token.

The unit tests are changed to use `FormatTestBase.h` because we need the
2-argument version of `verifyFormat`.  We also added the `messUp`
virtual function because Verilog needs a different version of it.

Reviewed By: HazardyKnusperkeks

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

[clang-format] Don't format already formatted integer literals

Fixes a bug in IntegerLiteralSeparatorFixer::checkSeparator() so that
only unformatted integer literals will be formatted.

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

[examples] Add export_executable_symbols to HowToUseLLJIT example.

LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper)
that will be defined in the executable when LLVM is linked statically.

Should fix https://github.com/llvm/llvm-project/issues/61712.

[clang-tidy] Add option to ignore user-defined literals in readability-magic-numbers

Some user-defined literals operate on implementation-defined types, like
"unsigned long long" and "long double", which are not well supported by
this check. Currently, the check gives warnings when using UDLs, without
giving possiblity to the user to whitelist common UDLs. A good compromise
until a proper fix is found (if any) is to allow the user to disable
warnings on UDLs.

Partially fixes #61656

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

[clang][RISCV] Fix ABI lowering for _Float16 for FP ABIs

For trivial cases (`_Float16` as a standalone argument), it was
previously correctly lowered to half. But the logic for catching cases
involving structs was gated off, as at the time that logic was written
the ABI for half was unclear.

This patch fixes that and adds a release note.

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

[clang][RISCV][test] Add test cases for empty structs and the FP calling conventions

As reported in https://github.com/llvm/llvm-project/issues/58929, Clang
currently differs from GCC in the handling of empty structs. This commit
adds some test coverage for the handling of such structs.

A follow-up patch implements a fix to match g++.

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

[RISCV] Make RISCVISAInfo::toFeatureVector ignore unsupported extensions

parseNormalizedArchString adds a code path that creates a RISCVISAInfo
including extensions that may not be supported by LLVM (rather than
erroring or just ignoring them). Therefore, toFeatureVector needs to
check the extension is supported in order to avoid creating unrecognised
feature strings.

This change shouldn't impact any code paths used outside of test code,
but this will be relied upon by the next patch which moves llvm-objdump
and related tools over to using parseNormalizedArchString.

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

[include-cleaner] Fix crash on unresolved headers

Make sure unresolved headers are not analyzed as part of unused
includes.

Also introduces a testing fixture for analyze tests

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

[Local] Preserve !nonnull only when K dominate J and K has a !noundef

Similar to D142687

Reviewed By: nikic

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

[gn build] Port 52296f5ed88b

AMDGPU: Add baseline test for SWDEV-380865

This demonstrates really bad rematerialization support
for 64-bit constants which need to be split into 32-bit pieces.

AMDGPU: Convert test to generated checks

InstCombine: Introduce new is.fpclass from logic of fcmp

Fixes regressions from patch to turn more classes into fcmp.

[clang-tidy] Correct union & macros handling in modernize-use-equals-default

To this moment this check were ignoring only inline
union special members, From now also out-of-line
special members going to be ignored. Also extended
support for IgnoreMacros to cover also macros used
inside a body, or used preprocesor directives.

Fixes:
 - https://github.com/llvm/llvm-project/issues/28300
 - https://github.com/llvm/llvm-project/issues/40554

Reviewed By: alexander-shaposhnikov

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

[clang-tidy] Add readability-avoid-unconditional-preprocessor-if check

Check flags always enabled or disabled code blocks in preprocessor '#if'
conditions, such as '#if 0' and '#if 1' etc.

Reviewed By: carlosgalvezp

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

[flang][nfc] Remove unused codes in idioms.h

Since D137859, these have not been used.

Reviewed By: Renaud-K

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

[ThinLTO] Only import for non-prevailing interposable global variables

This logic was added in https://reviews.llvm.org/D95943 specifically to
handle an issue for non-prevailing global variables. It turns out that
it adds a new issue for prevailing glboal variables, since those could
be replaced by an available_externally definition and hence incorrectly
omitted from the output object file. Limit the import to non-prevailing
global variables to fix this, as suggested by @tejohnson.

The bulk of the diff is mechanical changes to thread isPrevailing
through to where it's needed and ensure it's available before the
relevant calls; the actual logic change itself is straightforward.

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

Reviewed By: tejohnson

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

[RISCV] Move PseudoRVVInitUndef pseudos to RISCVInstrInfoVPseudos.td. NFC

Revert "[llvm] Teach GlobalDCE about dso_local_equivalent"

This reverts commit 86dbcafd0cdc88ae85896c6f12ecaa6006aeba54.

Reverting since this depends on db288184765c0b4010060ebea1f6de3ac1f66445
which broke our lto builders reported by fxbug.dev/12380.

Revert "[llvm] Teach whole program devirtualization about relative vtables"

This reverts commit db288184765c0b4010060ebea1f6de3ac1f66445.

Reverting since it broke our lto builders reported by fxbug.dev/123807.

[clang-format] Treat NTTP default values as expressions

clang-format already has logic to threat the right-hand side of an
equals sign. This patch applies that logic to template defaults,
which are likely to be non-template type parameters in which case the
default value should be annotated as an expression.
This should mostly only ever apply to bool and &&.

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

Reviewed By: MyDeveloperDay, owenpan

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

[clang-format] Don't wrap struct return types as structs

When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
we're dealing with a struct or class, however, this check is faulty if
it's actually a function with an elaborated struct/class return type, as
is common in C.

This patch skips the check if the brace is already annotated as
FunctionLBrace, in which case we already know it's a function and should
be treated as such.

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

Reviewed By: HazardyKnusperkeks, owenpan

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

[clang-format] Annotate lambdas with requires clauses.

The C++ grammar allows lambdas to have a *requires-clause* in two
places, either directly after the *template-parameter-list*, such as:

`[] <typename T> requires foo<T> (T t) { ... };`

Or, at the end of the *lambda-declarator* (before the lambda's body):

`[] <typename T> (T t) requires foo<T> { ... };`

Previously, these cases weren't handled at all, resulting in weird
results.

Note that this commit only handles token annotation, so the actual
formatting still ends up suboptimal. This is mostly because I do not yet
know how to approach making the requires clause formatting of lambdas
match the formatting for functions.

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

Reviewed By: HazardyKnusperkeks, owenpan

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

[MLIR][Affine] add memory effect traits for dmaOp

DmaOp will read the source buffer and write the destination buffer so need to add some traits for it.

Reviewed By: bondhugula

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

[MachineCopyPropagation] Pass DestSourcePair to isBackwardPropagatableCopy. NFC

Instead of calling isCopyInstr again, just pass the DestSourcePair
from the isCopyInstr call from the caller.

[ARM] Add some tests for non-zero VCTP generation. NFC

See D146517.

[libc] Add missing cast in fputil sqrt code

A cast is necessary to avoid implicit narrowing warnings
when those are enabled.

Reviewed By: abrachet

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

[MLIR][Affine] Fix/improve affine sibling fusion

The sibling fusion profitability checks shouldn't rely on the presence
of a store op in the sibling. The reuse is between the loads.

Fixes issues raised at https://discourse.llvm.org/t/understanding-the-affine-loop-fusion-pass/69452

Reviewed By: dcaballe

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

[Matrix] Extend test coverage for dot product lowering.

Extra tests:
* result is used by instruction
* constant vector operands
* multiply fed by other math instructions
* extra test with larger stride

[Matrix] Split up dot product tests into integer and float variants.

To avoid the individual files getting too big with further additions.

[clang-format] Handle Verilog assign statements

Reviewed By: MyDeveloperDay

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

[clang-format] More work on space around operators in Verilog

before:
```
(opcode *>o1) = 6.1;
a inside{b, c};
x = { >> {j}};
```

after:
```
(opcode *> o1) = 6.1;
a inside {b, c};
x = {>>{j}};
```

Reviewed By: MyDeveloperDay

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

[AMDGPUUnifyDivergentExitNodes] Add NewPM support

Meanwhile, use UniformityAnalysis instead of LegacyDivergenceAnalysis to collect divergence info.

Reviewed By: arsenm, sameerds

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