This patch introduces a new VPDef class, which can be used to
manage VPValues defined by recipes/VPInstructions.

The idea here is to mirror VPUser for values defined by a recipe. A
VPDef can produce either zero (e.g. a store recipe), one (most recipes)
or multiple (VPInterleaveRecipe) result VPValues.

To traverse the def-use chain from a VPDef to its users, one has to
traverse the users of all values defined by a VPDef.

VPValues now contain a pointer to their corresponding VPDef, if one
exists. To traverse the def-use chain upwards from a VPValue, we first
need to check if the VPValue is defined by a VPDef. If it does not have
a VPDef, this means we have a VPValue that is not directly defined
iniside the plan and we are done.

If we have a VPDef, it is defined inside the region by a recipe, which
is a VPUser, and the upwards def-use chain traversal continues by
traversing all its operands.

Note that we need to add an additional field to to VPVAlue to link them
to their defs. The space increase is going to be offset by being able to
remove the SubclassID field in future patches.

Reviewed By: Ayal

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

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27416

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

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

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

This wasn't properly remapping the type like with the other
attributes, so this would end up hitting a verifier error after
linking different modules using byref.

Reviewed By: dylanmckay

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

If the data member pointer is mapped, the compiler tries to optimize the
mapping of such data by discarding explicit mapping flags and trying to
emit combined data instead. In some cases, this optimization is not
quite correctly implemented and it leads to a program crash at the
runtime. Instead, if the data member is mapped, just emit it as is and
do not emit combined mapping flags for it.

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

This patch adds a new test cases which uses a matrix value as memory
inline assembly argument. Currently the pointer element type does not
match the vector type.

For the scattered operands of load instructions it makes sense
to use gathering load intrinsic, which can lower to native instruction
for X86/AVX512 and ARM/SVE. This also enables building
vectorization tree with entries containing scattered operands.
The next step is to add scattered store.

Fixes PR47629 and PR47623

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

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

Lax vector conversions was behaving incorrectly for implicit casts
between scalable and fixed-length vector types. For example, this:

    #include <arm_sve.h>

    #define N __ARM_FEATURE_SVE_BITS
    #define FIXED_ATTR __attribute__((arm_sve_vector_bits(N)))

    typedef svfloat32_t fixed_float32_t FIXED_ATTR;

    void allowed_depending() {
      fixed_float32_t fs32;
      svfloat64_t s64;

      fs32 = s64;
    }

... would fail because the vectors have differing lane sizes. This patch
implements the correct behaviour for
-flax-vector-conversions={none,all,integer}. Specifically:

- -flax-vector-conversions=none prevents all lax vector conversions
  between scalable and fixed-sized vectors.
- -flax-vector-conversions=integer allows lax vector conversions between
  scalable and fixed-size vectors whose element types are integers.
- -flax-vector-conversions=all allows all lax vector conversions between
  scalable and fixed-size vectors (including those with floating point
  element types).

The implicit conversions are implemented as bitcasts.

Reviewed By: fpetrogalli

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

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

This missing dependency has been causing the Flang buildbots
(with BUILD_SHARED_LIBS set to ON) to fail:
  * http://lab.llvm.org:8011/#/builders/66/builds/542
  * http://lab.llvm.org:8011/#/builders/33/builds/764

This missing dependency was exposed by this change:
  * https://reviews.llvm.org/D91461
This change is fine - the root cause of the failing builds is the
missing dependency.

When processing conditional branches, if the condition is an AND of 2 compares
and the true successor only has the current block as predecessor, queue both
conditions for the true successor.

LLVM style puts both gtest and gmock to the end of the include list.
But llvm-include-order-check was only moving gtest headers to the end, resulting
in a false tidy-warning.

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

In the wake of https://reviews.llvm.org/D89559, we discovered that a
couple of tests (the ones modified below to have additional triple
versions) would fail on Win32, for 1 of two reasons.  We seem to not
have a win32 buildbot anymore, so the triple is to make sure this
doesn't get broken in the future.

First, two of the three 'note-candidate' functions weren't appropriately
skipping the remaining conversion functions.

Second, in 1 situation (note surrogate candidates) we actually print the
type of the conversion operator.  The two tests that ran into that
needed updating to make sure it printed the proper one in the win32
case.

This relands https://reviews.llvm.org/D91059 and reverts commit
30fded75.

GetRegUsage now returns 0 when Ty is not a valid vector element type.

Implement JumpTable to make BRIND work on VE.  Update an existing
br_jt regression test also.

Reviewed By: simoll

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

Canonicalize extract_element(tensor_cast(v)) to just extract_element(v).

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

The shape of the result of a dynamic_tensor_from_elements is defined via its
result type and operands. We already fold dim operations when they reference
one of the statically sized dimensions. Now, also fold dim on the dynamically
sized dimensions by picking the corresponding operand.

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

This enables the use of fusion on buffers in partially lowered
programs.

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

https://reviews.llvm.org/D90039 breaks VE backend.  So, fix it.

Reviewed By: simoll

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

It may be necessary for interface methods to process or return variables with
the interface class type, in particular for attribute and type interfaces that
can return modified attributes and types that implement the same interface.
However, the code generated by ODS in this case would not compile because the
signature (and the body if provided) appear in the definition of the Model
class and before the interface class, which derives from the Model. Change the ODS
interface method generator to emit only method declarations in the Model class
itself, and emit method definitions after the interface class. Mark as "inline"
since their definitions are still emitted in the header and are no longer
implicitly inline. Add a forward declaration of the interface class before the
Concept+Model classes to make the class name usable in declarations.

Reviewed By: rriddle

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

The "module_terminator" op now has a custom syntax and therefore is
printed without quotes. Adapt Python tests to check for this syntax.

Simplifies code in some places and is more explicit about what is being used.
No additional includes were added here so no impact on compile time.

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

We typically use X32 for gnux32 triples

AddCXXStdlibLibArgs args were using the names for the clang equivalent methods.

Silences cppcheck warnings.

This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send registers in a
way that their offset fields can be re-constructed based on register sizes
in the increasing order of register number.

In context to Arm64 SVE, FPCR and FPSR are same registers in FPU regset and
SVE regset. Previously FPSR/FPCR offset was set at the end of SVE data
because Linux ptrace data placed FPCR and FPSR at the end of SVE register set.

Considering interoperability with other stubs like QEMU and that g packets
should generate register data in increasing order of register numbers. We
have to move FPCR/FPSR offset up to its original location according to
register numbering scheme of ARM64 registers with SVE registers included.

Reviewed By: labath

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

A common routine is to have the compiler crash, and attempt to rerun the
cc1 command-line by copying and pasting the arguments printed by
`llvm::Support::PrettyStackProgram::print`. However, these arguments are
not quoted or escaped which means they must be manually edited before
working correctly. This patch ensures that shell-unfriendly characters
are C-escaped, and arguments with spaces are double-quoted reducing the
frustration of running cc1 inside a debugger.

As the quoting is C, this is "best effort for most shells", but should
be fine for at least bash, zsh, csh, and cmd.exe.

Reviewed by: jhenderson

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

In our recent discussion we are aiming to make LLDB registers exchange minimum
possible information in qRegisterInfo or XMl register descriptions.
For SVE registers, Z registers are catagorized as primary registers and should
not have any infomration about any pseudo registers. All pseudo registers
should have the information on which primary register they belong to.
This patch removes invalidate_regs list from Z registers and will mitigate its
impact on SVE resize patch in a follow up update.

Reviewed By: labath

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

This patch uses the new `getMnemonic` helper from D90039
to display mnemonics instead of the internal opcodes.

The main motivation behind using the mnemonics is that they
are more user-friendly and more directly related to the assembly
the users will be presented.

Reviewed By: paquette

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