This avoids checking the size of the sequence repeatedly for each
special case. Especially on RV32 where none of the special cases
apply.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D152300
As pointed out in D149968 vselect predicate patterns could do with a one-use
check to prevent multiple operations being created. This updates the
EitherVSelectOrPassthruPatFrags pattern frags used in creating predicates
min/max.
Differential Revision: https://reviews.llvm.org/D151080
Otherwise subsequent .option arch, +foo directives (but not -, since
those have their own separate validation) fail the parseFeatureBits
check, leading to cascading errors.
Reviewed By: luismarques, MaskRay
Differential Revision: https://reviews.llvm.org/D152273
Where C is a simm32.
This costs an extra temporary register, but avoids a constant pool.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D152236
This property was intended to indicate when RISCVAsmPrinter should
drop the tied source operand when converting to MCInst. Using it
in RISCVDAGToDAGISel distorts what it intended for.
This should remove some changes from D151850.
Reviewed By: frasercrmck, asb
Differential Revision: https://reviews.llvm.org/D152039
The current interface requires some rather ugly tracking of state due to
splitting up the calls for each argument. Instead, pack them all into a
single call by passing an ArrayRef. Also clean up the dodgy whitespace
emitted for the directive whilst here; there was a stray space between
the tab and .option, and there was a tab rather than a space after the
first comma for some strange reason.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152193
Currently the early-return flow in the infinite loop makes it hard to
find the non-error termination points amongst the sea of errors. Rewrite
it with a more conventional control flow that has a clear loop guard (in
place of one of the early returns) and a break (in place of the other),
and with greater code reuse.
This has a small effect on the errors given for malformed input, as seen
in the affected test, and is probably more helpful as a result. Note
that we also bail early now if parseComma fails, as is standard.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D152192
Removing them seems to slightly increase code quality as well as
simplifying both the tablegen and C++ parts of the code.
Differential Revision: https://reviews.llvm.org/D149853
Most indexed vector instructions are suffixed with v<N><TY>_indexed.
SQRDMLAH/SQRDMLSH are the exception, being suffixed with <TY>_indexed
instead, which can complicate matching them slightly.
Differential Revision: https://reviews.llvm.org/D152161
New metadata format contains full calculation of field contents for
ps_extra_lds_size (vs old format where the value in RSRC register is used by PAL
to calculate the value required).
Also stop updating float_mode and rely on front end settings for this field.
Differential Revision: https://reviews.llvm.org/D152247
This is the same as D100412.
We just found the same crash when we tried to compile some packages
like mariadb, php, etc.
For constraint "o", it means "A memory operand is allowed, but
only if the address is offsettable". So I think it can be handled
just like constraint "m" for RISCV target.
And we print verbose information when unsupported constraints occur.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D151979
Fix for D151797 where the change accidentally allowed exit to
exact mode between branch instructions.
Reviewed By: dstuttard
Differential Revision: https://reviews.llvm.org/D152228
This brings the list of extensions supported here up to date
with what is supported by current git versions of binutils.
Also add a comment to AArch64TargetParser to remind people to
consider adding new ones to the list supported in assembly.
In the case of the "rdma" extension, there's a slight surprise:
LLVM knows of the extension under the name "rdm", while binutils
has it named "rdma". However, binutils appears to accept any
abbreviated prefix of an arch extension, so it does accept the
form "rdm" too even if it formally considers it called "rdma".
Support both spellings for the extensions here, for simplicity.
Differential Revision: https://reviews.llvm.org/D151981
When splitting a simm32 into LUI+ADDI(W). Subtract Lo12 from Val
to calculate Hi20. This replaces the old method of adding 0x800 to
Val. This change makes the math the reverse of how the LUI+ADDI(W)
create the immediate.
Since vfclass intruction will only set one single bit in the result, so if we only want to check 1 fp class, we could use vmseq to do it.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D151967
This patch lowers to vsetvli when the AVL is i32 or XLenVT and
the VF is a power of 2 in the range [1, 64]. VLEN=32 is not supported
as we don't have a valid type mapping for that. VF=1 is not supported
with Zve32* only.
The element width is used to set the SEW for the vsetvli if possible.
Otherwise we use SEW=8.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D150824
Add a DAG combine to form these from FADD_VL/FSUB_VL and FP_EXTEND_VL.
This makes it similar to other widening ops and allows us to handle
using the same FP_EXTEND_VL for both operands.
Differential Revision: https://reviews.llvm.org/D151969
i16/f16/bf16 will use the same .b16 registers and
i32/v2f16 and v2bf16 will share .b32 registers.
The changes are mostly mechanical, intended to remove unnecessary register
classes which tend to produce redundant register moves.
Differential Revision: https://reviews.llvm.org/D151601
v2f16 regtype conversion to i32
Define the function @llvm.amdgcn.make.buffer.rsrc, which take a 64-bit
pointer, the 16-bit stride/swizzling constant that replace the high 16
bits of an address in a buffer resource, the 32-bit extent/number of
elements, and the 32-bit flags (the latter two being the 3rd and 4th
wards of the resource), and combines them into a ptr addrspace(8).
This intrinsic is lowered during the early phases of the backend.
This intrinsic is needed so that alias analysis can correctly infer
that a certain buffer resource points to the same memory as some
global pointer. Previous methods of constructing buffer resources,
which relied on ptrtoint, would not allow for such an inference.
Depends on D148184
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D148957
1. Remove the existing code that would encode the constant offsets (if
there were any) on buffer intrinsic operations onto their
`MachineMemOperand`s. As far as I can tell, this use of `offset` has
no substantial impact on the generated code, especially since the same
reasoning is performed by areMemAccessesTriviallyDisjoint().
2. When a buffer resource intrinsic takes a pointer argument as the
base resource/descriptor, place that memory argument in the value
field of the MachineMemOperand attached to that intrinsic.
This is more conservative than what would be produced by more typical
LLVM code using GEP, as the Value (for alias analysis purposes)
corresponding to accessing buffer[0] and buffer[1] is the same.
However, the target-specific analysis of disjoint offsets covers a lot
of the simple usecases.
Despite this limitation, the new buffer intrinsics, combined with
LLVM's existing pointer annotations, allow for non-trivial
optimizations, as seen in the new tests, where marking two buffer
descriptors "noalias" allows merging together loads and stores in a
"load from A, modify loaded value, store to B" sequence, which would
not be possible previously.
Depends on D147547
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D148184
In order to enable the LLVM frontend to better analyze buffer
operations (and to potentially enable more precise analyses on the
backend), define versions of the raw and structured buffer intrinsics
that use `ptr addrspace(8)` instead of `<4 x i32>` to represent their
rsrc arguments.
The new intrinsics are named by replacing `buffer.` with `buffer.ptr`.
One advantage to these intrinsic definitions is that, instead of
specifying that a buffer load/store will read/write some memory, we
can indicate that the memory read or written will be based on the
pointer argument. This means that, for example, a read from a
`noalias` buffer can be pulled out of a loop that is modifying a
distinct buffer.
In the future, we will define custom PseudoSourceValues that will
allow us to package up the (buffer, index, offset) triples that buffer
intrinsics contain and allow for more precise backend analysis.
This work also enables creating address space 7, which represents
manipulation of raw buffers using native LLVM load and store
instructions.
Where tests simply used a buffer intrinsic while testing some other
code path (such as the tests for VGPR spills), they have been updated
to use the new intrinsic form. Tests that are "about" buffer
intrinsics (for instance, those that ensure that they codegen as
expected) have been duplicated, either within existing files or into
new ones.
Depends on D145441
Reviewed By: arsenm, #amdgpu
Differential Revision: https://reviews.llvm.org/D147547
This allows us to remove the uimm5 argument and changes the
scheduler class from ALU to Shift.
Ultimately we need a WShift scheduler class, but we need to scrub
all of the crypto instructions for scheduler classes so I'll leave
that for future work.
Reviewed By: 4vtomat, ego
Differential Revision: https://reviews.llvm.org/D152030
For image and buffer stores the default behaviour on GFX11 and
older is to set all unset components to zero. So if we pass
only X component it will be the same as X000, or XY same as XY00.
This patch simplifies the passed vector of components in InstCombine
by removing zero components from the end.
For image stores it also trims DMask if necessary.
Reviewed by: arsenm, foad, nhaehnle, piotr
