public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jiufu Guo <guojiufu@linux.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	dje.gcc@gmail.com, linkw@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH]rs6000: Load high and low part of 64bit constant independently
Date: Mon, 28 Nov 2022 10:35:36 +0800	[thread overview]
Message-ID: <7elenv24cn.fsf@pike.rch.stglabs.ibm.com> (raw)
In-Reply-To: <2de1185f-8de0-85a8-3d84-121f31fbd630@linux.ibm.com> (Kewen Lin's message of "Mon, 28 Nov 2022 09:50:41 +0800")


Hi Kewen/Segher,

Thanks a lot for your review!

I updated the patch accordingly as below for message/code/testcase:

For a complicate 64bit constant, blow is one instruction-sequence to
build:
	lis 9,0x800a
	ori 9,9,0xabcd
	sldi 9,9,32
	oris 9,9,0xc167
	ori 9,9,0xfa16

while we can also use below sequence to build:
	lis 9,0xc167
	lis 10,0x800a
	ori 9,9,0xfa16
	ori 10,10,0xabcd
	rldimi 9,10,32,0
This sequence is using 2 registers to build high and low part firstly,
and then merge them.

In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
register with potential register pressure).

The instruction sequence with two registers for parallel version can be
generated only if can_create_pseudo_p.  Otherwise, the one register
sequence is generated.

Bootstrap and regtest pass on ppc64le.
Is this ok for trunk?

gcc/ChangeLog:

	* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Generate
	more parallel code if can_create_pseudo_p.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/parall_5insn_const.c: New test.

---
 gcc/config/rs6000/rs6000.cc                   | 45 +++++++++++--------
 .../gcc.target/powerpc/parall_5insn_const.c   | 27 +++++++++++
 2 files changed, 53 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index eb7ad5e954f..877b314a57a 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -10337,26 +10337,33 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
     }
   else
     {
-      temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
-
-      emit_move_insn (copy_rtx (temp),
-		      GEN_INT (((ud4 << 16) ^ 0x80000000) - 0x80000000));
-      if (ud3 != 0)
-	emit_move_insn (copy_rtx (temp),
-			gen_rtx_IOR (DImode, copy_rtx (temp),
-				     GEN_INT (ud3)));
+      if (can_create_pseudo_p ())
+	{
+	  /* lis H,U4; ori H,U3; lis L,U2; ori L,U1; rldimi L,H,32,0.  */
+	  rtx high = gen_reg_rtx (DImode);
+	  rtx low = gen_reg_rtx (DImode);
+	  HOST_WIDE_INT num = (ud2 << 16) | ud1;
+	  rs6000_emit_set_long_const (low, (num ^ 0x80000000) - 0x80000000);
+	  num = (ud4 << 16) | ud3;
+	  rs6000_emit_set_long_const (high, (num ^ 0x80000000) - 0x80000000);
+	  emit_insn (gen_rotldi3_insert_3 (dest, high, GEN_INT (32), low,
+					   GEN_INT (0xffffffff)));
+	}
+      else
+	{
+	  /* lis A,U4; ori A,U3; rotl A,32; oris A,U2; ori A,U1.  */
+	  emit_move_insn (dest,
+			  GEN_INT (((ud4 << 16) ^ 0x80000000) - 0x80000000));
+	  if (ud3 != 0)
+	    emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud3)));
 
-      emit_move_insn (ud2 != 0 || ud1 != 0 ? copy_rtx (temp) : dest,
-		      gen_rtx_ASHIFT (DImode, copy_rtx (temp),
-				      GEN_INT (32)));
-      if (ud2 != 0)
-	emit_move_insn (ud1 != 0 ? copy_rtx (temp) : dest,
-			gen_rtx_IOR (DImode, copy_rtx (temp),
-				     GEN_INT (ud2 << 16)));
-      if (ud1 != 0)
-	emit_move_insn (dest,
-			gen_rtx_IOR (DImode, copy_rtx (temp),
-				     GEN_INT (ud1)));
+	  emit_move_insn (dest, gen_rtx_ASHIFT (DImode, dest, GEN_INT (32)));
+	  if (ud2 != 0)
+	    emit_move_insn (dest,
+			    gen_rtx_IOR (DImode, dest, GEN_INT (ud2 << 16)));
+	  if (ud1 != 0)
+	    emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud1)));
+	}
     }
 }
 
diff --git a/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
new file mode 100644
index 00000000000..e3a9a7264cf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -mno-prefixed -save-temps" } */
+/* { dg-require-effective-target has_arch_ppc64 } */
+
+/* { dg-final { scan-assembler-times {\mlis\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mori\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
+
+void __attribute__ ((noinline)) foo (unsigned long long *a)
+{
+  /* 2 lis + 2 ori + 1 rldimi for each constant.  */
+  *a++ = 0x800aabcdc167fa16ULL;
+  *a++ = 0x7543a876867f616ULL;
+}
+
+long long A[] = {0x800aabcdc167fa16ULL, 0x7543a876867f616ULL};
+int
+main ()
+{
+  long long res[2];
+
+  foo (res);
+  if (__builtin_memcmp (res, A, sizeof (res)) != 0)
+    __builtin_abort ();
+
+  return 0;
+}
-- 
2.17.1

BR,
Jeff (Jiufu)


"Kewen.Lin" <linkw@linux.ibm.com> writes:

> Hi Segher,
>
> on 2022/11/25 23:46, Segher Boessenkool wrote:
>> Hi!
>> 
>> On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
>>> "Kewen.Lin" <linkw@linux.ibm.com> writes:
>>>> on 2022/9/15 16:30, Jiufu Guo wrote:
>>>>> For a complicate 64bit constant, blow is one instruction-sequence to
>>>>> build:
>>>>> 	lis 9,0x800a
>>>>> 	ori 9,9,0xabcd
>>>>> 	sldi 9,9,32
>>>>> 	oris 9,9,0xc167
>>>>> 	ori 9,9,0xfa16
>>>>>
>>>>> while we can also use below sequence to build:
>>>>> 	lis 9,0xc167
>>>>> 	lis 10,0x800a
>>>>> 	ori 9,9,0xfa16
>>>>> 	ori 10,10,0xabcd
>>>>> 	rldimi 9,10,32,0
>>>>> This sequence is using 2 registers to build high and low part firstly,
>>>>> and then merge them.
>>>>> In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
>>>>> register with potential register pressure).
>> 
>> And crucially this patch only uses two registers if can_create_pseudo_p.
>> Please mention that.
>> 
>>>>> 	* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Update 64bit
>>>>> 	constant build.
>> 
>> If you don't give details of what this does, just say "Update." please.
>> But update to what?
>> 
>> "Generate more parallel code if can_create_pseudo_p." maybe?
>> 
>>>>> +	  rtx H = gen_reg_rtx (DImode);
>>>>> +	  rtx L = gen_reg_rtx (DImode);
>> 
>> Please don't use all-uppercase variable names, those are for macros.  In
>> fact, don't use uppercase in variable (and function etc.) names at all,
>> unless there is a really good reason to.
>> 
>> Just call it "high" and "low", or "hi" and "lo", or something?
>> 
>>>>> --- /dev/null
>>>>> +++ b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
>>>>> @@ -0,0 +1,27 @@
>>>>> +/* { dg-do run } */
>>>>> +/* { dg-options "-O2 -mdejagnu-cpu=power7  -save-temps" } */
>>>>
>>>> Why do we need power7 here?
>>> power8/9 are also ok for this case.  Actually, O just want to
>>> avoid to use new p10 instruction, like "pli", and then selected
>>> an old arch option.
>> 
>> Why does it need _at least_ p7, is the question (as I understand it).
>> 
>
> Yeah, that's what I was intended to ask, since those insns to be scanned
> don't actually require Power7 or later.
>
>> To prohibit pli etc. you can do -mno-prefixed (which works on all older
>> CPUs just as well), or skip the test if prefixed insns are enabled, or
>> scan for the then generated code as well.  The first option is by far
>> the simplest.
>
> Yeah, using -mno-prefixed is perfect here, nice!
>
> BR,
> Kewen

      reply	other threads:[~2022-11-28  2:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-15  8:30 Jiufu Guo
2022-11-25  9:15 ` Kewen.Lin
2022-11-25 13:21   ` Jiufu Guo
2022-11-25 13:31     ` Jiufu Guo
2022-11-25 15:46     ` Segher Boessenkool
2022-11-27 13:09       ` Jiufu Guo
2022-11-28  1:50       ` Kewen.Lin
2022-11-28  2:35         ` Jiufu Guo [this message]

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=7elenv24cn.fsf@pike.rch.stglabs.ibm.com \
    --to=guojiufu@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=linkw@gcc.gnu.org \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.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).