[RISCV] Disable subregister liveness by default

We previously enabled subregister liveness by default when compiling
with RVV. This has been shown to cause miscompilations where RVV
register operand

[RISCV] Disable subregister liveness by default

We previously enabled subregister liveness by default when compiling
with RVV. This has been shown to cause miscompilations where RVV
register operand constraints are not met. A test was added for this in
D129639 which explains the issue in more detail.

Until this issue is fixed in some way, we should not be enabling
subregister liveness unless the user asks for it.

Reviewed By: craig.topper, rogfer01, kito-cheng

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

show more ...

[RISCV] Add macrofusion infrastructure and one example usage.

This adds the macrofusion plumbing and support fusing LUI+ADDI(W).

This is similar to D73643, but handles a different case. Other cases

[RISCV] Add macrofusion infrastructure and one example usage.

This adds the macrofusion plumbing and support fusing LUI+ADDI(W).

This is similar to D73643, but handles a different case. Other cases
can be added in the future.

Reviewed By: reames

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

show more ...

Recommit "[RISCV] Enable subregister liveness tracking for RVV."

The failure that caused the previous revert has been fixed
by https://reviews.llvm.org/D126048

Original commit message:

RVV makes h

Recommit "[RISCV] Enable subregister liveness tracking for RVV."

The failure that caused the previous revert has been fixed
by https://reviews.llvm.org/D126048

Original commit message:

RVV makes heavy use of subregisters due to LMUL>1 and segment
load/store tuples. Enabling subregister liveness tracking improves the quality
of the register allocation.

I've added a command line that can be used to turn it off if it causes compile
time or functional issues. I used the command line to keep the old behavior
for one interesting test case that was testing register allocation.

Reviewed By: kito-cheng

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

show more ...

Revert "[RISCV] Enable subregister liveness tracking for RVV."

This reverts most of ed242b54c9c2aa84a47f66af5b8497d93646b68d

I'm seeing failures in our intrinsic testing on qemu that seem
related t

Revert "[RISCV] Enable subregister liveness tracking for RVV."

This reverts most of ed242b54c9c2aa84a47f66af5b8497d93646b68d

I'm seeing failures in our intrinsic testing on qemu that seem
related to this. Reverting while I investigate.

I've left the command line option in place for directed testing.
It defaults to off.

show more ...

[RISCV] Enable subregister liveness tracking for RVV.

RVV makes heavy use of subregisters due to LMUL>1 and segment
load/store tuples. Enabling subregister liveness tracking improves the quality
of

[RISCV] Enable subregister liveness tracking for RVV.

RVV makes heavy use of subregisters due to LMUL>1 and segment
load/store tuples. Enabling subregister liveness tracking improves the quality
of the register allocation.

I've added a command line that can be used to turn it off if it causes compile
time or functional issues. I used the command line to keep the old behavior
for one interesting test case that was testing register allocation.

Reviewed By: frasercrmck

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

show more ...

[RISCV] Add a special case to treat riscv-v-vector-bits-min=-1 as meaning use Zvl*b value.

riscv-v-vector-bits-min is primarily used to opt-in to the
autovectorizer. The vector width can be determin

[RISCV] Add a special case to treat riscv-v-vector-bits-min=-1 as meaning use Zvl*b value.

riscv-v-vector-bits-min is primarily used to opt-in to the
autovectorizer. The vector width can be determined from Zvl*b.

This patch adds support treating -1 as meaning use Zvl*b so we can
still opt-in to autovectorization without needing to repeat a
vector width already given by Zvl*b or -mcpu.

Reviewed By: reames

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

show more ...

[RISCV] Remove riscv-v-fixed-length-vector-elen-max command line option.

This was added before Zve extensions were defined. I think users
should use Zve32x or Zve32f now. Though we will lose support

[RISCV] Remove riscv-v-fixed-length-vector-elen-max command line option.

This was added before Zve extensions were defined. I think users
should use Zve32x or Zve32f now. Though we will lose support for limiting
ELEN to 16 or 8, but I hope no one was using that.

Reviewed By: frasercrmck

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

show more ...

[RISCV] Support 'generic' as a valid CPU name.

Most other targets support 'generic', but RISCV issues an error.
This can require a special case in tools that use LLVM that aren't
clang.

This patch

[RISCV] Support 'generic' as a valid CPU name.

Most other targets support 'generic', but RISCV issues an error.
This can require a special case in tools that use LLVM that aren't
clang.

This patch treats "generic" the same as an empty string and remaps
it to generic-rv/rv64 based on the triple. Unfortunately, it has to
be added to RISCV.td because MCSubtargetInfo is constructed and
parses the CPU before RISCVSubtarget's constructor gets a chance
to remap it. The CPU will then reparsed and the state in the
MCSubtargetInfo subclass will be updated again.

Fixes PR54146.

Reviewed By: khchen

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

show more ...

[RISCV] Fix support of vlen = 64.

In the Zve* extensions, the vlen could be 64. This patch change the vlen constraint of low bound to 64.

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

[RISCV] Factor Zve32 support into RISCVSubtarget::getMaxELENForFixedLengthVectors.

This is needed to properly limit fractional LMULs for Zve32.

Add new RUN Zve32 RUN lines to the existing tests for

[RISCV] Factor Zve32 support into RISCVSubtarget::getMaxELENForFixedLengthVectors.

This is needed to properly limit fractional LMULs for Zve32.

Add new RUN Zve32 RUN lines to the existing tests for the
-riscv-v-fixed-length-vector-elen-max command line option.

show more ...

[RISCV] Add the zvl extension according to the v1.0 spec

`zvl` is the new standard vector extension that specifies the minimum vector length of the vector extension.
The `zvl` extension is related t

[RISCV] Add the zvl extension according to the v1.0 spec

`zvl` is the new standard vector extension that specifies the minimum vector length of the vector extension.
The `zvl` extension is related to the `zve` extension and other updates that are added in v1.0.

According to https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21,
Clang defines macro `__riscv_v_min_vlen` for `zvl` and it can be used for applications that uses the vector extension.
LLVM checks whether the option `riscv-v-vector-bits-min` (if specified) matches the `zvl*` extension specified.

Reviewed By: craig.topper

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

show more ...

[RISCV] Use constant pool for large integers

For large integers (for example, magic numbers generated by
TargetLowering::BuildSDIV when dividing by constant), we may
need about 4~8 instructions to b

[RISCV] Use constant pool for large integers

For large integers (for example, magic numbers generated by
TargetLowering::BuildSDIV when dividing by constant), we may
need about 4~8 instructions to build them.
In the same time, it just takes two instructions to load
constants (with extra cycles to access memory), so it may be
profitable to put these integers into constant pool.

Reviewed By: asb, craig.topper

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

show more ...

[RISCV] Replace most uses of RISCVSubtarget::hasStdExtV. NFCI

Add new hasVInstructions() which is currently equivalent.

Replace vector uses of hasStdExtZfh/F/D with new vector specific
versions. Th

[RISCV] Replace most uses of RISCVSubtarget::hasStdExtV. NFCI

Add new hasVInstructions() which is currently equivalent.

Replace vector uses of hasStdExtZfh/F/D with new vector specific
versions. The vector spec no longer requires that the vectors implement the
same types as scalar. It only requires that the scalar type is
the maximum size the vectors can support. This is currently
implemented using the scalar rule we were using before.

Add new hasVInstructionsI64() begin using to qualify code that
requires i64 vector elements.

This is all NFC for now, but we can start using this to better
implement D112408 which introduces the Zve extensions.

Reviewed By: frasercrmck, eopXD

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

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[RISCV] Add -riscv-v-fixed-length-vector-elen-max to limit the ELEN used for fixed length vectorization.

This adds an ELEN limit for fixed length vectors. This will scalarize
any elements larger tha

[RISCV] Add -riscv-v-fixed-length-vector-elen-max to limit the ELEN used for fixed length vectorization.

This adds an ELEN limit for fixed length vectors. This will scalarize
any elements larger than this. It will also disable some fractional
LMULs. For example, if ELEN=32 then mf8 becomes illegal, i32/f32
vectors can't use any fractional LMULs, i16/f16 can only use mf2,
and i8 can use mf2 and mf4.

We may also need something for the scalable vectors, but that has
interactions with the intrinsics and we can't scalarize a scalable
vector.

Longer term this should come from one of the Zve* features

show more ...

[RISCV] Make VLEN no greater than 65536

Reviewed By: craig.topper

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

[RISCV] Move getLMULForFixedLengthVector out of RISCVSubtarget.

Make it a static function RISCVISelLowering, the only place it
is used.

I think I'm going to make this return a fractional LMULs in s

[RISCV] Move getLMULForFixedLengthVector out of RISCVSubtarget.

Make it a static function RISCVISelLowering, the only place it
is used.

I think I'm going to make this return a fractional LMULs in some
cases so I'm sorting out where it should live before I start
making changes.

show more ...

[RISCV] Give an explicit error if 'generic' CPU is passed instead of 'generic-rv32' or 'generic-rv64'. Validate 64Bit feature against the triple.

I encountered a project that uses llvm that passes "

[RISCV] Give an explicit error if 'generic' CPU is passed instead of 'generic-rv32' or 'generic-rv64'. Validate 64Bit feature against the triple.

I encountered a project that uses llvm that passes "generic" by
default. While I could fix that project, I wouldn't be surprised
if other projects did something similar. So it seems like
a good idea to provide a better error here.

I've also added validation of the 64Bit feature against the
triple so that we can catch a mismatched CPU before failing in
a mysterious way. We can make it pretty far in isel because we
calculate XLenVT from the triple and use that to set up the legal
integer type.

Reviewed By: luismarques, khchen

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

show more ...

[RISCV] Add support loads, stores, and splats of vXi1 fixed vectors.

This refines how we determine which masks types are legal and adds
support for loads, stores, and all ones/zeros splats.

I left

[RISCV] Add support loads, stores, and splats of vXi1 fixed vectors.

This refines how we determine which masks types are legal and adds
support for loads, stores, and all ones/zeros splats.

I left a fixme in store handling where I think we need to zero
extra bits if the type isn't a multiple of a byte. If I remember
right from X86 there was some case we could have a store of a
1, 2, or 4 bit mask and have a scalar zextload that then expected the
bits to be 0. Its tricky to zero the bits with RVV. We need to do
something like round VL up, zero a register, lower the VL back down,
then do a tail undisturbed move into the zero register. Another
option might be to generate a mask of 1/2/4 bits set with a VL of 8
and use that to mask off the bits.

Reviewed By: frasercrmck

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

show more ...

[RISCV] Make the min and max vector width command line options more consistent and check their relationship to each other.

[RISCV] Initial support of LoopVectorizer for RISC-V Vector.

Define an option -riscv-vector-bits-max to specify the maximum vector
bits for vectorizer. Loop vectorizer will use the value to check if

[RISCV] Initial support of LoopVectorizer for RISC-V Vector.

Define an option -riscv-vector-bits-max to specify the maximum vector
bits for vectorizer. Loop vectorizer will use the value to check if it
is safe to use the whole vector registers to vectorize the loop.

It is not the optimum solution for loop vectorizing for scalable vector.
It assumed the whole vector registers will be used to vectorize the code.
If it is possible, we should configure vl to do vectorize instead of
using whole vector registers.

We only consider LMUL = 1 in this patch.

This patch just an initial work for loop vectorizer for RISC-V Vector.

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

show more ...

[RISCV] Add initial support for converting fixed vectors to scalable vectors during lowering to use RVV instructions.

This is an alternative to D95563.

This is modeled after a similar feature for A

[RISCV] Add initial support for converting fixed vectors to scalable vectors during lowering to use RVV instructions.

This is an alternative to D95563.

This is modeled after a similar feature for AArch64's SVE that uses
predicated scalable vector instructions.a

Rather than use predication, this patch uses an explicit VL operand.
I've limited it to always use LMUL=1 for now, but we can improve this
in the future.

This requires a bunch of new ISD opcodes to carry the VL operand.
I think we can probably lower intrinsics to these ISD opcodes to
cut down on the size of the isel table. Which is why I've added
patterns for all integer/float types and not just LMUL=1.

I'm only testing one vector width right now, but the width is
programmable via the command line.

Reviewed By: frasercrmck

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

show more ...

[RISCV] Add -mtune support

- The goal of this patch is improve option compatible with RISCV-V GCC,
-mcpu support on GCC side will sent patch in next few days.

- -mtune only affect the pipeline

[RISCV] Add -mtune support

- The goal of this patch is improve option compatible with RISCV-V GCC,
-mcpu support on GCC side will sent patch in next few days.

- -mtune only affect the pipeline model and non-arch/extension related
target feature, e.g. instruction fusion; in td file it called
TuneFeatures, which is introduced by X86 back-end[1].

- -mtune accept all valid option for -mcpu and extra alias processor
option, e.g. `generic`, `rocket` and `sifive-7-series`, the purpose is
option compatible with RISCV-V GCC.

- Processor alias for -mtune will resolve according the current target arch,
rv32 or rv64, e.g. `rocket` will resolve to `rocket-rv32` or `rocket-rv64`.

- Interaction between -mcpu and -mtune:
* -mtune has higher priority than -mcpu for pipeline model and
TuneFeatures.

[1] https://reviews.llvm.org/D85165

Reviewed By: luismarques

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

show more ...

[X86][MC][Target] Initial backend support a tune CPU to support -mtune

This patch implements initial backend support for a -mtune CPU controlled by a "tune-cpu" function attribute. If the attribute

[X86][MC][Target] Initial backend support a tune CPU to support -mtune

This patch implements initial backend support for a -mtune CPU controlled by a "tune-cpu" function attribute. If the attribute is not present X86 will use the resolved CPU from target-cpu attribute or command line.

This patch adds MC layer support a tune CPU. Each CPU now has two sets of features stored in their GenSubtargetInfo.inc tables . These features lists are passed separately to the Processor and ProcessorModel classes in tablegen. The tune list defaults to an empty list to avoid changes to non-X86. This annoyingly increases the size of static tables on all target as we now store 24 more bytes per CPU. I haven't quantified the overall impact, but I can if we're concerned.

One new test is added to X86 to show a few tuning features with mismatched tune-cpu and target-cpu/target-feature attributes to demonstrate independent control. Another new test is added to demonstrate that the scheduler model follows the tune CPU.

I have not added a -mtune to llc/opt or MC layer command line yet. With no attributes we'll just use the -mcpu for both. MC layer tools will always follow the normal CPU for tuning.

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

show more ...

Revert "[TableGen][GlobalISel] Account for HwMode in RegisterBank register sizes"

This reverts commit e9f22fd4293a65bcdcf1b18b91c72f63e5e9e45b.

When building with -DLLVM_USE_SANITIZER="Thread", che

Revert "[TableGen][GlobalISel] Account for HwMode in RegisterBank register sizes"

This reverts commit e9f22fd4293a65bcdcf1b18b91c72f63e5e9e45b.

When building with -DLLVM_USE_SANITIZER="Thread", check-llvm has 70
failing tests with this revision, and 29 without this revision.

show more ...