Adding the td definitions, and their associated assembly and disassembly
test cases for the decimal floating point test instructions defined in
section 5.6.3 of ISA 3.1
Reviewed By: lei, amyk
Differential Revision: https://reviews.llvm.org/D154606
Add td definitions and asm/disasm tests for the dfp format
instructions in ISA 3.1 section 5.6.6
Reviewed By: stefanp, kamaub
Differential Revision: https://reviews.llvm.org/D154465
Prepare for removing the MemOpsEmitted workaround for symbolic
displacements by letting TableGen know about the offsets of the
displacement sub-operands within the instruction.
There are alternative ways to do this that were tried and rejected:
- Creating encoders and decoders for each possible displacement offset.
This is too repetitive.
- Use VarLenCodeEmitter [1]. The resulting diff is quite large.
Instead, use the named sub-operand support introduced by commit
a538d1f13a13 ("[TableGen][CodeEmitterGen] Allow local names for
sub-operands in a operand list.").
Describe instruction encodings in terms of sub-operands instead of
operands (e.g. B, D, L vs BDL) - this also better matches the pictures
from the Principles of Operation. Decompose operands into sub-operands
using the new (bdaddr12only $B1, $D1):$BD1 syntax. Replace the
encoders and the decoders of the operands with these of the
sub-operands.
Since DecodeADDR64BitRegisterClass() is now used for bases and indices,
change it to return NoRegister when decoding 0. This also changes the
disassembly of some instructions, e.g., br %r0 becomes br 0. Since this
better captures the instruction semantics, namely, that the value of
%r0 is not used, keep this change and update the tests.
[1] https://m680x0.github.io/blog/2022/02/varlen-encoder.html
Reviewed By: uweigand
Differential Revision: https://reviews.llvm.org/D155194
Add td definitions and asm/disasm tests for the quantum conversion
instructions in ISA 3.1 section 5.6.5
Reviewed By: stefanp
Differential Revision: https://reviews.llvm.org/D154394
Add td definitions and asm/disasm tests for the quantum adjustment
instructions in ISA 3.1 section 5.6.4
Reviewed By: stefanp
Differential Revision: https://reviews.llvm.org/D154369
Patch eece6ba283bd changed the src1 type of v_ldexp_f16 from i32 to
i16. Though semantically src1 is an i16, the hardware reads this operand as an
f16 type, which primarily enables floating point inline constants.
Therefore this patch changes the operand type to f16. It maintains the
current behavior where floating point source modifiers are not allowed
on src1. SDWA sext modifier continues to be allowed.
The test asm and disasm test changes in eece6ba283bd are reverted,
because the floating point inline constants are allowed.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D153169
AMDGPU has native instructions and target intrinsics for this, but
these really should be subject to legalization and generic
optimizations. This will enable legalization of f16->f32 on targets
without f16 support.
Implement a somewhat horrible inline expansion for targets without
libcall support. This could be better if we could introduce control
flow (GlobalISel version not yet implemented). Support for strictfp
legalization is less complete but works for the simple cases.
My previous patch had added a couple of asserts to the disassembler.
The problem with this is that the disassembler is not just used for the
text section it is also used to disassemble the data section of an
object where the bytes do not necessarily represent instructions. If the
data in the data section happens to look like an illegal instruction
then llvm-objdump will assert on data because it is finding an illegal
instruction that is not actually an instruction at all.
Reviewed By: nemanjai, #powerpc
Differential Revision: https://reviews.llvm.org/D149711
This patch adds the DFP mul and div instructions. This includes both the
double and quad forms of the instructions as well as the record form.
Reviewed By: amyk
Differential Revision: https://reviews.llvm.org/D150787
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
The logic from line 633 to 640 is specific for ARM as the comments said, it will make all the targets will prefer to using instruction with more predicates when compiler do AsmMatching.
And for code from line 642 to 649, X86 want to use the order records written in source file to sort the instructions. So X86 could be affected by this logic. (These code could be arrived only by X86)
After change this, seems AVX instructions have not be affected but it exposed some other errors for instruction push and call.
CALLpcrel16 could not be used in 64 bit mode, we need add Predicate for it. And for push instruction, previously because pushi32 has predicates = [Not64bitmode], so it precede pushi16, which is incorrect here, we should get pushw here and it also align with gcc.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D150436
Add the following Decimal Floating Point (DFP) instructions for PowerPC.
dadd, daddq, dsub, dsubq
In order to add these instructions a new register class for a pair
of floating point registers is added.
This patch is only to allow the user to specify the instructions in
assembly. There is no scheduling or patterns for the instructions.
Reviewed By: amyk
Differential Revision: https://reviews.llvm.org/D148597
- FP registers and register classes definitions
- MC support for FP registers
- MC support for the FPDR -> FPDR variant of FMOVE/FSMOVE/FDSMOVE
Note that we don't implement 32/64-bit FP registers with subregisters since
f32/f64 values will be converted to f80 upon storing into a register,
rather than occupying part of the register.
So we only use register classes with different value types to distinguish
them.
Differential Revision: https://reviews.llvm.org/D147480
This makes it possible to use TRAP to make Linux system calls using
inline assembly for instance.
Differential Revision: https://reviews.llvm.org/D147102
FEAT_ATS1A adds three new AT system instruction aliases. This feature is
optional from v8.9a/v9.4a. FEAT_ATS1A is a very late addition to the
2022 A-profile VMSA extension, and has not yet been added to the public
docs available on developer.arm.com
These AT instructions are added without a command-line flag or feature,
because it is system-instruction only, and FEAT_S1PIE also has no
command-line flag.
Differential Revision: https://reviews.llvm.org/D146962
This implements support for two new 2022 A-profile extensions:
- FEAT_CHK - Check Feature Status Extension
- FEAT_GCS - Guarded Control Stacks
FEAT_CHK is mandatory from armv8.0-a, but is in the hint space so
there's no clang command-line flag for it, and we only print the hint as
`chkfeat x16` at v8.9a and above, to be compatible when using a
non-integrated assembler that might not yet know about the extension.
FEAT_GCS is optional from armv9.4-a onwards. It is enabled using `+gcs`
in a clang `-march=` or `-mcpu=` option string, or using a
`.arch_extension gcs` assembly directive.
This patch includes changes by Ties Stuij, Tomas Matheson, and Keith
Walker.
Differential Revision: https://reviews.llvm.org/D145563
Image sample instructions that need more than 5 VGPRs for VAddr can use
partial NSA for NSA encoding format. VGPRs that can not fit into the
encoding are sequential after the last one.
This patch adds assembly and disassembly parts.
Differential Revision: https://reviews.llvm.org/D144033
Before this patch
```
$ echo "leal (,%r15), %eax" | llvm-mc --show-encoding --output-asm-variant=1
lea eax, [r15] # encoding: [0x42,0x8d,0x04,0x3d,0x00,0x00,0x00,0x00]
$ echo "lea eax, [r15]" | llvm-mc --show-encoding -x86-asm-syntax=intel --output-asm-variant=1
lea eax, [r15] # encoding: [0x41,0x8d,0x07]
```
MC printed the register r15 as a base in intel syntax even when it's an index.
Then we got a different encoding by using the assembly from the output of the
first command.
I believe the behavior is too weird to be called a feature.
After this patch, we get
```
$ echo "leal (,%r15), %eax" | llvm-mc --show-encoding --output-asm-variant=1
lea eax, [1*r15] # encoding: [0x42,0x8d,0x04,0x3d,0x00,0x00,0x00,0x00]
```
Reviewed By: RKSimon, pengfei, MaskRay
Differential Revision: https://reviews.llvm.org/D144183
These are similar to hardware registers already added for GFX940,
but with different numbers and slightly different names.
Differential Revision: https://reviews.llvm.org/D143740
In the GFX11 VINTERP encoding bits 23, 59 and 60 are unused. Change the
disassembler to ignore these bits.
Differential Revision: https://reviews.llvm.org/D143633
There is an assert in the disassembler functions to ensure
that the immediate is the appropriate width. However,
sometimes what is being disassembled is not instructions
but data that happens to have the bit pattern of an existing
instruction but invalid operands. It is valid for such
things to exist in the text section so we don't want
to crash when disassembling such a thing.
This patch removes the asserts and produces a disassembler
failure for such cases.
decodeFPImmed creates immediate operand using register operand width,
but size of created immediate should correspond to OperandType for
RegisterOperand.
e.g. OPW128 could be used for RegisterOperands that use v2f64 v4f32
and v8f16. Each RegisterOperands would have different OperandType and
require that immediate is decoded using 64, 32 and 16 bit immediate
respectively.
decodeOperand_<RegClass> only provides width for register decoding,
introduce decodeOperand_<RegClass>_Imm<ImmWidth> that also provides
width for immediate decoding.
Refactor RegisterOperands:
- decoders get _Imm<ImmWidth> suffix in some cases
- removed unused RegisterOperands defined via multiclass
- use different RegisterOperand in a few places, new RegisterOperand's
decoder corresponds to the number of bits used for operand's encoding
Refactor decoder functions:
- add asserts for the size of encoding that will be decoded
- regroup them according to the method of decoding
decodeOperand_<RegClass> (register only, no immediate) decoders can now
create immediate of consistent size, use it for better diagnostic of
'invalid immediate'.
Differential Revision: https://reviews.llvm.org/D142636
The previous T2 ADC instruction requires three operands. This patch
supports its shortened forms.
Differential Revision: https://reviews.llvm.org/D141853
32-bit immediates require special cares because they go across the
normal word (16 bits) boundaries.
This patch also fixes some incorrect disassembler test cases.
Differential Revision: https://reviews.llvm.org/D142080
The Ampere1A core improves on the Ampere1 with key differences being:
* memory tagging is supported
* SM3/SM4 are supported
* adds a new fusion pair for (A+B+1 and A-B-1)
(added in a later commit)
Depends on D142395
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D142396
This adds support for the missing `PIRE0_EL12` system register, part of
v8.9-A/v9.4-A's Permission Indirection Extension.
Patch by Son Tuan Vu.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D141400
The `CNTPCTSS_EL0` and `CNTVCTSS_EL0` system registers, part of
Armv8.6-A's Enhanced Counter Virtualization extension (FEAT_ECV), are
described as read-only in the Arm ARM. This updates their implementation
to match the spec.
Original patch by Simon Tatham.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D141398
The encodings of these 2 RME MEC instructions are
incorrect and need swapping:
- DC CIPAE
- DC CIGDPAE
The correct encoding is:
Operation op0 op1 CRn CRm op2
DC CIPAE, Xt 0b01 0b100 0b0111 0b1110 0b000
DC CIGDPAE, Xt 0b01 0b100 0b0111 0b1110 0b111
Differential Revision: https://reviews.llvm.org/D141689
The previous vnmul only accepts three registers. It should accept either
two or three registers as vmul does.
Differential Revision: https://reviews.llvm.org/D141405
