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.

This reverts commit 8c7c1f11.

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

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 e0ad2af6 ("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

Reviewed By: aaron.ballman

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

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

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

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

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

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

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

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

Reviewed By: foad

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

This reverts commit 9c4611f9.

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

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

Patch By: ipriyanshi1708

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

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

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

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

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

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

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

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

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

This is a workaround until D144193 has landed.

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

Reviewed By: craig.topper

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

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

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

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.

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

Reviewed By: mgorny

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

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

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

Add missing bang operators and reorder them in alphabetical order.

Reviewed By: craig.topper

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

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