RVV stands for "RISC-V V Extension", which adds 32 vector registers, and seven unprivileged CSRs (vstart, vxsat, vxrm, vcsr, vtype, vl, vlenb) to a base scalar RISC-V ISA.

The base vector extension is intended to provide general support for data-parallel execution within the 32-bit instruction encoding space, with later vector extensions supporting richer functionality for certain domains.

This patch adds the definitions of RVV registers in `RegisterInfos_riscv64.h`, whose purpose is to provide support (such as reading, writing, and calculating the offsets) for future register-related functions.

Reviewed By: kito-cheng

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

This will be used for writing test cases.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

The array component indices in the "path" of a fir.slice are zero based
because FIR does not know about the component lower bounds.
When lowering hlfir.designate to FIR for `array%x(i, j)`, convert `i` and
`j` to zero based indices before generating the fir.slice.

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

There are some patterns in td files without MVT/class set
for some operands in target pattern that are from the source
pattern. This prevents GlobalISelEmitter from adding them as
a valid rule, because the target child operand is an
unsupported kind operand. For now, for a leaf child, only
IntInit and DefInit are handled in GlobalISelEmitter.

This issue can be workaround by adding MVT/class to the
patterns in the td files, like the workarounds for patterns
anyext and setcc in PPCInstrInfo.td in D140878.

To avoid adding the same workarounds for other patterns in
td files, this patch tries to handle the UnsetInit case in
GlobalISelEmitter.

Adding the new handling allows us to remove the workarounds
in the td files and also generates many selection rules for
PPC target.

Reviewed By: arsenm

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

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

As noted in https://reviews.llvm.org/D148315, the ordering logic for
OrderedExtensionMap currently puts s* before z* extensions, but per the
ISA manual the correct order should be z* and then s* (with the
exception of zxm*, which are ordered after s*).

This patch fixes the ordering and adds a TODO for zxm*. The changes are
visible in the test case added in
a35e67fc which also demonstrates an
issue with the ordering of single letter extensions (which isn't
addressed in this patch).

This ordering matches the one used by GCC/binutils as well.

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

2a5661c8 added a new external link with
the link text "0.2 draft specification". Surprisingly, as multiple links
have this same text but different targets this causes a warning, which
causes a failure on the llvm-sphinx-docs builder (which treats warnings
as errors). As suggested in
<https://github.com/sphinx-doc/sphinx/issues/3921>, this commit moves to
using anonymous references for the links in the experimental extensions
section.

As we already do `unsigned Opcode = Inst.getOpcode();`, we may as well
use that variable.

As of
https://github.com/riscv/riscv-isa-manual/commit/1f038182810727f5feca311072e630d6baac51da
in the riscv-isa-manual, Zfa is at version 0.2. Reviewing the commit
history for
zfa.tex
<https://github.com/riscv/riscv-isa-manual/commits/master/src/zfa.tex>
there are no relevant changes since 0.1. As such, we can simply
increment the version number.

This change also removes the claim in RISCVUsage that we implement a
"subset of" Zfa, as I believe this is no longer true. That sentence
previously incorrectly claimed we didn't implement fli.{h,s,d} (I
[corrected this a couple of weeks
ago](https://reviews.llvm.org/rG3d969191b277)) but I think should have
removed the "subset of" wording too.

As was noted during the review, we never added Zfa to the release notes.
This is corrected in this patch.

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

The patch will caused dead loop because of DAGCombiner's canonicalization:
  // (x + C) - y  ->  (x - y) + C
  // y - (x + C)  ->  (y - x) - C
  // (x - C) - y  ->  (x - y) - C
  // (C - x) - y  ->  C - (x + y)

This reverts commit b3529b5b.

The patch lowers vector rint/nearbyint like vp.rint/nearbyint.

Reviewed By: craig.topper

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

For floating-point instructions, SEW won't be 8. So we don't need
to generate scheduling resources for it.

Reviewed By: michaelmaitland

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

* Remove unnecessary casts.
* Use concrete shaped types (e.g., `MemRefType`, `RankedTensorType`) instead of `ShapedType` when possible.
* Minor documentation cleanups.

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

This function returns incorrect values for memrefs and vectors due to "widening".

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

Reviewed By: razvanlupusoru, anlunx

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

This reverts commit d771f541 due to builder
failures, e.g. https://lab.llvm.org/buildbot#builders/93/builds/14488.

b3c696fb started using TestLogger in tests. This class depends on
write_to_stderr which was previously only provided for Linux and
GPU's. Note, this function is used on those platforms in the libc
proper, though for Fuchsia we only ever want to provide this for
TestLogger.

No CMake files are changed because this fuchsia/ directory isn't
useful in any CMake build.

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

Other OSes may have different mappings from error number to message.
This creates a system to allow new platforms to define their own
mappings.

Reviewed By: sivachandra

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

Buildbot reported undefined references to LLVM dialect and Memref
dialect. The issue is that OpenACC dialect now depends on those
(since it attaches interface to the types) but the cmake file
did not explicitly add those dependencies.

Reviewed By: clementval, vzakhari

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

`compressed(hi)` is similar to `compressed`, but instead of reusing the previous position high as the current position low, it uses a pair of positions for each sparse index.

The patch only introduces the definition (syntax) but does not provide codegen implementation.

Reviewed By: aartbik

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

As outlined in [1], data clauses are now implemented as separate operations
from the constructs that they belong to. Some of the highlighted benefits:
- Correctly represent dataflow of data operations
- Easier to track debugging information
- Friendlier to add attributes and to optimize operations

For now, all of the other operand lists are being kept until all references
to them in LLVM can be removed (such as those in flang lowering)

[1] https://discourse.llvm.org/t/rfc-openacc-dialect-data-operation-improvements/69825

Reviewed By: clementval, vzakhari

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

We reserved 16 AddrSpaces in every TypeSetByHwMode. But we only ever
use the first one on targets that make use of the AddrSpace feature.

The vector was populated by pushing for each entry in the ArrayRef
passed to the TypeSetByHwMode constructor. Each entry is a
ValueTypeByHwMode that stores one VT for each HwMode.

The vector is accessed by a loop in TypeSetByHwMode::getValueTypeByHwMode.
That loop is over HwModes with in the TypeSetByHwMode. This is
unrelated to how the vector was created. The entries in the vector
don't represent HwModes.

The targets that use AddrSpace don't make use of HwModes so the
loop in getValueTypeByHwMode will only run 1 iteration. So we only
the first entry in the vector is meaningful used.

This patch simplifies things by storing only 1 AddrSpace in
TypeSetByMode. Reducing the memory used by TypeSetByHwMode.
More work will be needed to support HwModes with AddrSpace if we
need a different AddrSpace for each HwMode.

Reviewed By: arsenm

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

This reverts commit 76e1521b.

Be explicit about the 32bitness of the return type.

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

Recommit "[ValueTracking] Apply the isKnownNonZero techniques in `ashr`/`lshl` to `shl` and vice-versa" (2nd Try)

Wasn't related to the bug it was original thought to be causing.

Wasn't related to the bug it was original thought to be causing.

Bug was because we recognized patterns like `(shl 4, Z)` as a power of
2 we could take Log2 of (`2 + Z`), but doing `(shl X, (2 + Z))` can
cause a poison shift.
    https://alive2.llvm.org/ce/z/yuJm_k

The fix is to verify that `Log2(Y)` will be a non-poisonous shift
amount. We can do this with:
    `nsw` flag:
        - https://alive2.llvm.org/ce/z/yyyJBr
        - https://alive2.llvm.org/ce/z/YgubD_
    `nuw` flag:
        - https://alive2.llvm.org/ce/z/-4mpyV
        - https://alive2.llvm.org/ce/z/a6ik6r
    Prove `Y != 0`:
        - https://alive2.llvm.org/ce/z/ced4su
        - https://alive2.llvm.org/ce/z/X-JJHb

Reviewed By: nikic

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

These tests passed on my ppc64le test machine. If they survive testing by the
buildbots then we can leave them enabled, and this will allow us to land the
new ppc64 JITLink backend (https://reviews.llvm.org/D148192).

The placement is currently wrong in the presence of function entry related
instrumentations (prefixdata, -fpatchable-function-entry=, -fsanitize=kcfi,
etc).

Employ a similar tactic introduced by https://reviews.llvm.org/D94362
for gwp_asan tests. zxtest `ASSERT_DEATH` syntax differs from gtest in
that it expects a lambda.

zxtest does not have `EXPECT_DEATH`, so it introduced for Fuchsia builds
and wraps the expression with a lambda to create a compatible syntax
between zxtest and gtest for death tests.

An example of where this compatiblity is needed is in
`never_allocated.cpp`.

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

This patch ports PerfJITEventListener to a JITLink plugin, but adds unwind record support and drops debuginfo support temporarily. Debuginfo can be enabled in the future by providing a way to obtain a DWARFContext from a LinkGraph.

See D146060 for an experimental implementation that adds debuginfo parsing.

Reviewed By: lhames

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

It's common to see such cases for contraction from convolution with
input channel as 3. Although we aren't utilizing all 4 lanes for
dot product, it should still be better than performing the multiply
and reduction separately.

Reviewed By: kuhar

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

The "getField" method is a bit confusing considering we also have a
"getFieldName" method. Instead, use "getFieldDecl" rather than
"getField".

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