From: Alan Modra <amodra@gmail.com>
To: binutils@sourceware.org
Subject: PowerPC64 paddi -Mraw
Date: Sat, 12 Nov 2022 17:29:51 +1030 [thread overview]
Message-ID: <Y29EZ/ykU1Qe6AAw@squeak.grove.modra.org> (raw)
On a testcase like
pla 8,foo@pcrel
disassembled with -Mpower10 results in
0: 00 00 10 06 pla r8,0 # 0
4: 00 00 00 39
0: R_PPC64_PCREL34 foo
but with -Mpower10 -Mraw
0: 00 00 10 06 .long 0x6100000
0: R_PPC64_PCREL34 foo
4: 00 00 00 39 addi r8,0,0
The instruction is unrecognised due to the hack we have in
extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as
pla. I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the
condition in extract_pcrel0 under which *invalid is set, but went for
this larger patch that reorders the extended insn pla to the more
usual place before its underlying machine insn. (la is after addi
because we never disassemble to la.)
gas/
* testsuite/gas/ppc/raw.d,
* testsuite/gas/ppc/raw.s: Add pla.
opcodes/
* ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and
invert *invalid logic.
(PCREL1): Rename from PCREL0.
(prefix_opcodes): Sort pla before paddi, adjusting R operand
for pla, paddi and psubi.
diff --git a/gas/testsuite/gas/ppc/raw.d b/gas/testsuite/gas/ppc/raw.d
index 133c8c4e0a0..a9cfa8b9cb1 100644
--- a/gas/testsuite/gas/ppc/raw.d
+++ b/gas/testsuite/gas/ppc/raw.d
@@ -60,3 +60,5 @@ Disassembly of section \.text:
c8: (7c 20 04 ac|ac 04 20 7c) sync 1,0
cc: (06 00 00 00|00 00 00 06) paddi r3,0,0,0
d0: (38 60 00 00|00 00 60 38)
+ d4: (06 10 00 00|00 00 10 06) paddi r3,0,0,1 # d4
+ d8: (38 60 00 00|00 00 60 38)
diff --git a/gas/testsuite/gas/ppc/raw.s b/gas/testsuite/gas/ppc/raw.s
index 874f0bc4722..09e145c81a1 100644
--- a/gas/testsuite/gas/ppc/raw.s
+++ b/gas/testsuite/gas/ppc/raw.s
@@ -50,3 +50,4 @@
mdoom
lwsync
pli 3,0
+ pla 3,0
diff --git a/opcodes/ppc-opc.c b/opcodes/ppc-opc.c
index 4d67d2581b1..57064ef3514 100644
--- a/opcodes/ppc-opc.c
+++ b/opcodes/ppc-opc.c
@@ -730,16 +730,16 @@ extract_pcrel (uint64_t insn,
return pcrel;
}
-/* Variant of extract_pcrel that sets invalid for R bit set. The idea
- is to disassemble "paddi rt,0,offset,1" as "pla rt,offset". */
+/* Variant of extract_pcrel that sets invalid for R bit clear. Used
+ to disassemble "paddi rt,0,offset,1" as "pla rt,offset". */
static int64_t
-extract_pcrel0 (uint64_t insn,
+extract_pcrel1 (uint64_t insn,
ppc_cpu_t dialect,
int *invalid)
{
int64_t pcrel = extract_pcrel (insn, dialect, invalid);
- if (pcrel)
+ if (!pcrel)
*invalid = 1;
return pcrel;
}
@@ -3344,13 +3344,13 @@ const struct powerpc_operand powerpc_operands[] =
#define PCREL_MASK (1ULL << 52)
{ 0x1, 52, insert_pcrel, extract_pcrel, PPC_OPERAND_OPTIONAL },
-#define PCREL0 PCREL + 1
- { 0x1, 52, insert_pcrel, extract_pcrel0, PPC_OPERAND_OPTIONAL },
+#define PCREL1 PCREL + 1
+ { 0x1, 52, insert_pcrel, extract_pcrel1, PPC_OPERAND_OPTIONAL },
/* The RA field in a D or X form instruction which is an updating
load, which means that the RA field may not be zero and may not
equal the RT field. */
-#define RAL PCREL0 + 1
+#define RAL PCREL1 + 1
{ 0x1f, 16, insert_ral, extract_ral, PPC_OPERAND_GPR_0 },
/* The RA field in an lmw instruction, which has special value
@@ -9749,9 +9749,9 @@ const unsigned int powerpc_num_opcodes = ARRAY_SIZE (powerpc_opcodes);
const struct powerpc_opcode prefix_opcodes[] = {
{"pnop", PMRR, PREFIX_MASK, POWER10, 0, {0}},
{"pli", PMLS|OP(14), P_DRAPCREL_MASK, POWER10, EXT, {RT, SI34}},
-{"paddi", PMLS|OP(14), P_D_MASK, POWER10, 0, {RT, RA0, SI34, PCREL0}},
-{"psubi", PMLS|OP(14), P_D_MASK, POWER10, EXT, {RT, RA0, NSI34, PCREL0}},
-{"pla", PMLS|OP(14), P_D_MASK, POWER10, EXT, {RT, D34, PRA0, PCREL}},
+{"pla", PMLS|OP(14), P_D_MASK, POWER10, EXT, {RT, D34, PRA0, PCREL1}},
+{"paddi", PMLS|OP(14), P_D_MASK, POWER10, 0, {RT, RA0, SI34, PCREL}},
+{"psubi", PMLS|OP(14), P_D_MASK, POWER10, EXT, {RT, RA0, NSI34, PCREL}},
{"xxsplti32dx", P8RR|VSOP(32,0), P_VSI_MASK, POWER10, 0, {XTS, IX, IMM32}},
{"xxspltidp", P8RR|VSOP(32,2), P_VS_MASK, POWER10, 0, {XTS, IMM32}},
{"xxspltiw", P8RR|VSOP(32,3), P_VS_MASK, POWER10, 0, {XTS, IMM32}},
--
Alan Modra
Australia Development Lab, IBM
reply other threads:[~2022-11-12 6:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y29EZ/ykU1Qe6AAw@squeak.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).