public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kewen.Lin" <linkw@linux.ibm.com>
To: Jiufu Guo <guojiufu@linux.ibm.com>
Cc: dje.gcc@gmail.com, segher@kernel.crashing.org, linkw@gcc.gnu.org,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] rs6000: using li/lis+oris/xoris to build constants
Date: Thu, 20 Oct 2022 17:29:37 +0800	[thread overview]
Message-ID: <a0051735-dfaf-1d8d-1973-226aea907050@linux.ibm.com> (raw)
In-Reply-To: <20220824081344.70468-1-guojiufu@linux.ibm.com>

Hi Jeff,

Sorry for late review, some comments are inline.

on 2022/8/24 16:13, Jiufu Guo via Gcc-patches wrote:
> Hi,
> 
> PR106708 constaint some constants which can be support by li/lis + oris/xoris.
> 
> For constant C:
> if ((c & 0xFFFFFFFF80008000ULL) == 0x80000000ULL) or say:
> 32(0)+1(1)+15(x)+1(0)+15(x), we could use li+oris to build constant 'C'.
> 
> if ((c & 0xFFFFFFFF00008000ULL) == 0xFFFFFFFF00008000ULL) or say:
> 32(1)+16(x)+1(1)+15(x), using li+xoris would be ok.
> 
> if ((c & 0xFFFFFFFF0000FFFFULL) == 0xFFFFFFFF00000000) or say:
> 32(1)+1(0)+15(x)+16(0), using lis+xoris would be ok.
> 

Maybe it's good to add some explanation on the proposed writing "N(M)"
N continuous bit M, (x for M means either 1 or 0), and not sure if it's
good to use "||" for concatenation just like what ISA uses, the con
is it can be mis-interpreted as logical "or".

Or maybe just expand all the low 32 bits and use "1..." or "0..." for the
high 32 bits.

> This patch update rs6000_emit_set_long_const to support these forms.
> Bootstrap and regtest pass on ppc64 and ppc64le.
> 
> Is this ok for trunk?
> 
> BR,
> Jeff(Jiufu)
> 
> 
> 	PR target/106708
> 
> gcc/ChangeLog:
> 
> 	* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Using li/lis +
> 	oris/xoris to build constants.

Nit: Support constants which can be built with li + oris or li/lis + xoris?

> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.target/powerpc/pr106708.c: New test.
> 	* gcc.target/powerpc/pr106708.h: New file.
> 	* gcc.target/powerpc/pr106708_1.c: New test.
> 
> ---
>  gcc/config/rs6000/rs6000.cc                   | 22 +++++++++++++++++++
>  gcc/testsuite/gcc.target/powerpc/pr106708.c   | 10 +++++++++
>  gcc/testsuite/gcc.target/powerpc/pr106708.h   |  9 ++++++++
>  gcc/testsuite/gcc.target/powerpc/pr106708_1.c | 17 ++++++++++++++
>  4 files changed, 58 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.c
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.h
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708_1.c
> 
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index df491bee2ea..243247fb838 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -10112,6 +10112,7 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
>  {
>    rtx temp;
>    HOST_WIDE_INT ud1, ud2, ud3, ud4;
> +  HOST_WIDE_INT orig_c = c;
>  
>    ud1 = c & 0xffff;
>    c = c >> 16;
> @@ -10137,6 +10138,27 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT c)
>  			gen_rtx_IOR (DImode, copy_rtx (temp),
>  				     GEN_INT (ud1)));
>      }
> +  else if (ud4 == 0 && ud3 == 0 && (ud2 & 0x8000) && !(ud1 & 0x8000))
> +    {
> +      temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> +
> +      /* li+oris */
> +      emit_move_insn (copy_rtx (temp), GEN_INT (ud1));

Nit: in previous discussion on some other patch, copy_rtx is not necessary?

> +      emit_move_insn (dest, gen_rtx_IOR (DImode, copy_rtx (temp),
> +					 GEN_INT (ud2 << 16)));
> +    }

I think this hunk above can be moved to the existing "(ud3 == 0 && ud4 == 0)"
handling branch (as the diff context below), and ud2 & 0x8000 is already
asserted there, it also saves check.

> +  else if ((ud4 == 0xffff && ud3 == 0xffff)
> +	   && ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000))))
> +    {
> +      temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> +
> +      HOST_WIDE_INT imm = (ud1 & 0x8000) ? ((ud1 ^ 0x8000) - 0x8000)
> +					 : ((ud2 << 16) - 0x80000000);
> +      /* li/lis + xoris */
> +      emit_move_insn (copy_rtx (temp), GEN_INT (imm));
> +      emit_move_insn (dest, gen_rtx_XOR (DImode, copy_rtx (temp),
> +					 GEN_INT (orig_c ^ imm)));
> +    }

Same comment for copy_rtx.

>    else if (ud3 == 0 && ud4 == 0)
>      {
>        temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708.c b/gcc/testsuite/gcc.target/powerpc/pr106708.c
> new file mode 100644
> index 00000000000..6445fa47747
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.c
> @@ -0,0 +1,10 @@
> +/* PR target/106708 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
> +/* { dg-do compile { target has_arch_ppc64 } } */
> +

Put dg-do as the first line, if you want has_arch_ppc64 to be behind dg-options,
separate it into a dg-require-effective-target.

> +#include "pr106708.h"
> +
> +/* { dg-final { scan-assembler-times {\mli\M} 2 } } */
> +/* { dg-final { scan-assembler-times {\mlis\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\moris\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mxoris\M} 2 } } */
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708.h b/gcc/testsuite/gcc.target/powerpc/pr106708.h
> new file mode 100644
> index 00000000000..ad07eb30547
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.h
> @@ -0,0 +1,9 @@
> +/* li/lis + oris/xoris */


Nit: /* Test constants which can be built from li + oris and li/lis + xoris.  */

> +void  __attribute__ ((__noinline__, __noclone__)) foo (long long *arg)
> +{
> +  *arg++ = 0x98765432ULL;
> +  *arg++ = 0xffffffff7cdeab55ULL;
> +  *arg++ = 0xffffffff65430000ULL;
> +}
> +
> +
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106708_1.c b/gcc/testsuite/gcc.target/powerpc/pr106708_1.c
> new file mode 100644
> index 00000000000..df65c321f6b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106708_1.c

Nit: better with name pr106708-run.c?

BR,
Kewen

> @@ -0,0 +1,17 @@
> +/* PR target/106708 */
> +/* { dg-do run } */
> +/* { dg-options "-O2" } */
> +
> +#include "pr106708.h"
> +
> +long long arr[] = {0x98765432ULL, 0xffffffff7cdeab55ULL, 0xffffffff65430000ULL};
> +int
> +main ()
> +{
> +  long long a[3];
> +
> +  foo (a);
> +  if (__builtin_memcmp (a, arr, sizeof (arr)) != 0)
> +    __builtin_abort ();
> +  return 0;
> +}


  parent reply	other threads:[~2022-10-20  9:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24  8:13 Jiufu Guo
2022-09-07  7:36 ` Ping " Jiufu Guo
2022-10-20  9:29 ` Kewen.Lin [this message]
2022-10-26  2:56   ` Jiufu Guo

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=a0051735-dfaf-1d8d-1973-226aea907050@linux.ibm.com \
    --to=linkw@linux.ibm.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=guojiufu@linux.ibm.com \
    --cc=linkw@gcc.gnu.org \
    --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).