With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with the shift-double ones.
While there also drop the APX form with ShiftCount omitted. Other shift
and rotate insns were deliberately left without this form as well. Note
that there's also no testsuite adjustment needed for this, indicating
that the form wasn't tested either.
With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with the "ordinary" shift and rotate ones.
While there also drop the APX form of RCL/RCR with Imm1 omitted. Other
shift insns as well as ROR/ROL were deliberately left without this form
as well. Note that there's also no testsuite adjustment needed for this,
indicating that the form wasn't tested either.
Furthermore since RCL/RCR already had non-NDD APX forms, those end up
being added for the other 6 mnemonics, too.
With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with a the more complex binary (two source) cases.
Note how this adds a missing CheckOperandSize to one of the APX sub
forms.
Furthermore since SBB already had a non-NDD APX form, one ends up
being added for the other 6 mnemonics, too.
With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with a few simple unary (single source) cases.
With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Start with the simplest case, accompanied by a necessary adjustment to
i386-gen (such that template uses can also be at the start of a line).
While there also drop a bogus (meaningless / unreachable) "break" as
well as a unused variable (which I'm surprised compilers didn't warn
about).
The following instructions are added in this patch:
- ADDPT (predicated): Add checked pointer vectors (predicated).
- ADDPT (unpredicated): Add checked pointer vectors (unpredicated).
- SUBPT (predicated): Subtract checked pointer vectors (predicated).
- SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated).
- MADPT: Multiply-add checked pointer vectors, writing multiplicand
- MLAPT: Multiply-add checked pointer vectors, writing addend
These instructions are part of Checked Pointer Arithmetic extension
and are enabled when both CPA and SVE are enabled. To achieve this,
both flag "+sve" and "+cpa" should be active.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
The following instructions are added in this patch:
- ADDPT and SUBPT - Add/Subtract checked pointer
- MADDPT and MSUBPT - Multiply Add/Subtract checked pointer
These instructions are part of Checked Pointer Arithmetic extension.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
A new flag "+cpa" added to documentation. This flag enables CPA extension.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
Except for bfml{a,s} their 1st and 3rd operands need to match - pass
the TIED macro argument accordingly. While doing that also slightly
re-arrange table entries, such that all predicated insns are close
together.
At the same time change the existing test source to actually use non-
matching operands for the respective bfml{a,s} forms.
Their index is in bits 19, 20, and 22. Bit 11 in particular is already
set in the base opcode. Note also how disassembler output didn't match
assembler input in the respective testcase.
Irrespective of the encoding being EVEX, the usable SIMD register range
continues to be limited to %xmm0-%xmm15. Enforce this in gas (but
continue to generate code, as in principle we know how to encode
things) and recognize/flag the case in the disassembler.
Oddly enough wrong forms were actually used in the testsuite (register-
only forms are then really meaningless to test here, and are hence
dropped instead of adjusted).
Convert the POP2 test that needs touching anyway (due to a bad ModR/M
byte having been chosen) to .insn.
Base and index register 0 have no effect in address computation:
"A value of zero in the B [base] or X [index] field specifies that no
base or index is to be applied, and, thus, general register 0 cannot be
designated as containing a base address or index."
IBM z/Architecture Principles of Operation [1], chapter "Organization",
section "General Registers".
Index register 0 is omitted in the s390 disassembly. Base register 0 is
omitted in D(B), D(L,B) and D(X,B) - the latter only if the index
register is zero.
To make it more apparent print base register 0 as "0" instead of "%r0",
whenever it would still be printed in the disassembly.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-dis.c: Print base register 0 as "0" in disassembly.
binutils/
* NEWS: Mention base register 0 now being printed as "0" in s390
disassembly.
gas/
* testsuite/gas/s390/zarch-base-index-0.d: Update test case
output verification patterns to accept "0" as base base
register due to disassembler output format change.
* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Print a warning message when the register type of a specified register
name does not match with the operand's register type:
operand {#}: expected {access|control|floating-point|general|vector}
register name [as {base|index} register]
Introduce a s390-specific assembler option "warn-regtype-mismatch"
with the values "strict", "relaxed", and "no" as well as an option
"no-warn-regtype-mismatch" which control whether the assembler
performs register name type checks and generates above warning messages.
warn-regtype-mismatch=strict:
Perform strict register name type checks.
warn-regtype-mismatch=relaxed:
Perform relaxed register name type checks, which allow floating-point
register (FPR) names %f0 to %f15 to be specified as argument to vector
register (VR) operands and vector register (VR) names %v0 to %v15 to
be specified as argument to floating-point register (FPR) operands.
This is acceptable as the FPRs are embedded into the lower halves of
the VRs. Make "relaxed" the default, as GCC generates assembler code
using FPR and VR interchangeably, which would cause assembler warnings
to be generated with "strict".
warn-regtype-mismatch=no:
no-warn-regtype-mismatch:
Disable any register name type checks.
Tag .insn pseudo mnemonics as such, to skip register name type checks
on those. They need to be skipped, as there do not exist .insn pseudo
mnemonics for every possible operand register type combination. Keep
track of the currently parsed operand number to provide it as reference
in warning messages.
To verify that the introduction of this change does not unnecessarily
affect the compilation of existing code the GNU Binutils, GNU C Library,
and Linux Kernel have been build with the new assembler, verifying that
the assembler did not generate any of the new warning messages.
gas/
* config/tc-s390.c: Handle new assembler options
"[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate
parsed register expressions with register type. Keep track of
operand number being parsed. Print warning message in case of
register type mismatch between instruction operand and parsed
register expression.
* doc/as.texi: Document new s390-specific assembler options
"[no-]warn-regtype-mismatch[=strict|relaxed|no]".
* NEWS: Mention new s390-specific register name type checks and
related assembler option "warn-regtype-mismatch=strict|
relaxed|no".
* testsuite/gas/s390/s390.exp: Add test cases for new assembler
option "warn-regtype-mismatch={strict|relaxed}".
* testsuite/gas/s390/esa-g5.s: Fix register types in tests for
didbr, diebr, tbdr, and tbedr.
* testsuite/gas/s390/zarch-z13.s: Fix register types in tests
for vgef, vgeg, vscef, and vsceg.
* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s:
Tests for assembler option "warn-regtype-mismatch=strict".
* testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l:
Likewise.
* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s:
Tests for assembler option "warn-regtype-mismatch=relaxed".
* gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l:
Likewise.
* gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update
test cases for assembler option "warn-regtype-mismatch"
defaulting to "relaxed".
* testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise.
include/
* opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add
instruction flag to tag .insn pseudo-mnemonics.
opcodes/
* s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as
such.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
While at it add comments to logic to omit base and/or index register 0
in s390 disassembly.
opcodes/
* s390-dis.c: Add comments related to omitting base and/or index
register 0 in disassembly.
gas/
* testsuite/gas/s390/s390.exp: Add test cases for base and/or
index register 0.
* testsuite/gas/s390/zarch-base-index-0.s: Add test cases for
base and/or index register 0.
* testsuite/gas/s390/zarch-base-index-0.d: Likewise.
* testsuite/gas/s390/zarch-base-index-0-err.s: Add error test
cases for base and/or index register 0.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
opcodes/
* s390-mkopc.c: Use proper string lengths when parsing opcode
table flags.
Fixes: c5306fed7d ("s390: Support for jump visualization in disassembly")
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
While most logic in optimize_encoding() is already covering APX by way
of the earlier NDD->REX2 conversion, there's a remaining set of cases
which wants handling separately.
gas/
* tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi,
%tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype
renamed to percent_op_relax_only as this matcher is extended to handle
jalr as well which is not R-type.
(riscv_ip): Apply the percent_op_relax_only rename and update comment.
(md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to
TLS relocation check list.
* testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation
generation.
opcodes/
* riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with
%tlsdesc_call annotations.
Hi,
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion.
Regression tested on aarch64-none-elf, and no regression found.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001
From: Matthieu Longo <matthieu.longo@arm.com>
Date: Fri, 23 Feb 2024 11:30:40 +0000
Subject: [PATCH] aarch64: rename internals related to PAuth feature to use
pauth in their naming for coherency
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature
with internal names that don't match the actual feature name pauth. The new
feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature
of Armv8.3-A. Using a different naming for it not based on the formerly "PAC"
would create confusion.
Next to code using %ymm<N> or %zmm<N> it is more natural to have .cfi_*
directives also reference those, not the corresponding %xmm<N>. Accept
their names as kind of aliases, i.e. resolving to the same numbers.
While extending the respective 64-bit testcase, also add %bnd<N> there
(should have happened right with 633789901c ["x86-64: Dwarf2 register
numbers for %bnd<N>"], sorry), requiring binutils/dwarf.c to be adjusted
accordingly as well.
While various other entries in version 003 of the spec aren't quite as
explicit (due to simply leaving the respective field blank), all three
have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0
by default (and respect -mevexwig=).
Most registers from a register-pair suffixed by .lo and .hi suffixes.
This was not the case of $r14 and $r15 since they are defined by the
ABI: $r14 is the frame pointer, and $r15 is used to return aggregates
from functions. We do not add aliases for $r12 (the stack pointer) and
$r13 (the tls register).
opcodes/ChangeLog:
* kvx-opc.c: Regenerate.
gas/ChangeLog:
* config/kvx-parse.h: Regenerate.
TCA instructions start with an X, this introduces ambiguities when it
comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this
reason, we rename OR to IOR and XOR to EOR.
OR and XOR variants are still valid on KV3-1 and KV3-2. However, they
have been completely removed from KV4-1.
opcodes/ChangeLog:
* kvx-opc.c: Regenerate.
include/ChangeLog:
* opcode/kvx.h: Regenerate.
gas/ChangeLog:
* config/kvx-parse.h: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.
Hi,
[PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register
AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.
Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.
Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf?
Thanks,
Yury Khrustalev
From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001
From: Yury Khrustalev <yury.khrustalev@arm.com>
Date: Tue, 6 Feb 2024 11:05:39 +0000
Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the
id_aa64isar3_el1 system register
AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.
Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.
While necessary on the legacy encodings, the EVEX ones don't need it.
Even more so when they're available for 64-bit mode only, when the
legacy encodings have the attribute only for correctly handling things
in 16-bit mode.
Several years ago it was decided that SSE2AVX templates should not be
sensitive to -mvexwig= (upon my suggestion to consistently make all
sensitive as long as they don't require a specific setting of VEX.W).
Adjust the four that still are, switching to use of Vex128 at the same
time.
While e20298da05 ("Remove redundant Byte, Word, Dword and Qword from
insn templates") did so for Byte/Word/Dword/Qword, the same kind of
redundancy was left in place for a few 128-bit SIMD operands.
Albeit not being a currently valid BPF instruction, callx is generated
by both clang and GCC when BPF programs are compiled unoptimized.
Until now, GCC would emit it only whe using the experimental
compiler-testing cpu version xbpf, whereas clang would emit it from
v1. This patch makes GAS to accept callx also starting with cpu v1.
opcodes/ChangeLog
* bpf-opc.c: Move callx into the v1 BPF CPU variant.
gas/ChangeLog
* testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu
version.
* testsuite/gas/bpf/indcall-1.d: Likewise.
DBNZ instruction decrements its source register operand, and if
the result is non-zero it branches to the location defined by a signed
half-word displacement operand.
DBNZ instruction is in BRANCH class as other branch instrucitons
like B, Bcc, etc. However, DBNZ is the only branch instruction
that stores a branch offset in the second operand. Thus it must
be placed in a distinct class and treated differently.
For example, current logic of arc_insn_get_branch_target in GDB
assumes that a branch offset is always stored in the first operand
for BRANCH class and it's wrong for DBNZ.
include/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* opcode/arc.h (enum insn_class_t): Add DBNZ class.
opcodes/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* arc-tbl.h (dbnz): Use "DBNZ" class.
* arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class.
gas/ChangeLog:
2024-02-14 Yuriy Kolerov <ykolerov@synopsys.com>
* config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ".
Don't wander into three_byte_table[] when REX2 is present.
While there also eliminate related confusion when accessing
dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping
the odd variable gets things better in sync with 1-byte handling as
well.
Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't
even present in the x86-64-apx-egpr-inval testcase, hence why I
overlooked that these can actually be encoded, (again) using suitable
AVX512 counterparts.
While there also "modernize" the adjacent AVX/AVX2 entries.
Already the %bnd<N> registers used numbers beyond 127, and eGPR ones are
all out of reach for "signed char", at least when CHAR_BITS=8. Switch to
"unsigned char", covering appropriately in places where the value
returned for "none" actually matters (in tc_x86_parse_to_dw2regnum()
this is actually achieved by altering how X_op is set).
There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW.
For some reason we were (incorrectly) supporting these. This patch
updates the opcodes so the instructions get removed and modifies the
GAS manual and testsuite accordingly.
See discussion at
https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev
Tested in bpf-uknonwn-none target, x86-64-linux-gnu host.
include/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.
opcodes/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.
gas/ChangeLog:
2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com>
* doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit
load instruction.
(BPF Instructions): There is no absolute 64-bit load instruction.
* testsuite/gas/bpf/mem.s: Update test accordingly.
* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/mem.d: Likewise.
* testsuite/gas/bpf/mem.s: Likewise.
SHA512 instructions were added to the architecture at the same time as SHA3
instructions, but later than the SHA1 and SHA256 instructions. Furthermore,
implementations must support either both or neither of the SHA512 and SHA3
instruction sets. However, SHA512 instructions were originally (and
incorrectly) added to Binutils under the +sha2 flag.
This patch moves SHA512 instructions under the +sha3 flag, which matches the
architecture constraints and existing GCC and LLVM behaviour.
Re-using the entire VEX decode hierarchy for the respective major opcode
has led to those two also being decoded as-if valid. Follow the earlier
USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.
As suggested during review already, all such entries have their first
slot as Bad_Opcode, so by adding two more enumerators we can avoid doing
that decode step altogether.
With identical source and destination it can be covered by the NDD-to-
legacy conversion logic as well, even if in this case the original insn
doesn't use an NDD encoding. The size savings are even better here, for
the replacement (BSWAP) not having a ModR/M byte.
