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;
> +}
next prev 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).