From: Richard Biener <richard.guenther@gmail.com>
To: Richard Sandiford <richard.sandiford@arm.com>,
"Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com>,
Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [AArch64] Fix NEON load/store gimple lowering and big-endian testisms
Date: Fri, 5 Nov 2021 11:27:24 +0100 [thread overview]
Message-ID: <CAFiYyc3VRHoeuw=y6pCFNUKT2=HAfKG4WvvsHdFMz14F+5MZJQ@mail.gmail.com> (raw)
In-Reply-To: <mpta6ij7qx8.fsf@arm.com>
On Thu, Nov 4, 2021 at 6:49 PM Richard Sandiford via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> "Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com> writes:
> > Hi,
> >
> > This should address the ubsan bootstrap build and big-endian testisms
> > reported against the last NEON load/store gimple lowering patch. I also
> > fixed a follow-up issue where the alias information was leading to a bad
> > codegen transformation. The NEON intrinsics specifications do not forbid
> > the use of memory accesses with different pointer types. In fact you
> > will see intrinsic user code loading a int16x8_t vector from an int
> > pointer, so we must make sure GCC is aware a NEON memory access of an
> > 'int' pointer can alias with a 'short' pointer.
> >
> > Bootstrapped aarch64-linux-gnu (also did an ubsan bootstrap).
> >
> > Is this OK for trunk?
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-builtins.c
> > (aarch64_general_gimple_fold_builtin): Change pointer alignment and alias.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/fmla_intrinsic_1.c: Fix big-endian testism.
> > * gcc.target/aarch64/fmls_intrinsic_1.c: Likewise.
> > * gcc.target/aarch64/fmul_intrinsic_1.c: Likewise.
> >
> > diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
> > index a815e4cfbccab692ca688ba87c71b06c304abbfb..fc8fcb02c55e22963d2a3bf77b4749eb5b1c1561 100644
> > --- a/gcc/config/aarch64/aarch64-builtins.c
> > +++ b/gcc/config/aarch64/aarch64-builtins.c
> > @@ -2486,16 +2486,22 @@ aarch64_general_gimple_fold_builtin (unsigned int fcode, gcall *stmt,
> > aarch64_simd_type_info simd_type
> > = aarch64_simd_types[mem_type];
> > tree elt_ptr_type = build_pointer_type (simd_type.eltype);
> > + elt_ptr_type = build_distinct_type_copy (elt_ptr_type);
> > + TYPE_REF_CAN_ALIAS_ALL (elt_ptr_type) = true;
> > tree zero = build_zero_cst (elt_ptr_type);
> > gimple_seq stmts = NULL;
> > tree base = gimple_convert (&stmts, elt_ptr_type,
> > args[0]);
>
> This conversion seems redundant. Do things work if we use args[0]
> directly?
Just use
tree elt_ptr_type = build_pointer_type_for_mode (simd_type.eltype,
VOIDmode, true);
that will build a ref-all pointer for you, appropriately shared.
>
> > + /* Use element type alignment. */
> > + tree access_type
> > + = build_aligned_type (simd_type.itype,
> > + TYPE_ALIGN (TREE_TYPE (simd_type.itype)));
>
> I think simd_type.eltype is more natural than TREE_TYPE (simd_type.itype)
> here, to match the pointer target type.
>
> Same idea for the stores.
>
> > if (stmts)
> > gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
> > new_stmt
> > = gimple_build_assign (gimple_get_lhs (stmt),
> > fold_build2 (MEM_REF,
> > - simd_type.itype,
> > + access_type,
> > base, zero));
> > }
> > break;
> > @@ -2508,17 +2514,22 @@ aarch64_general_gimple_fold_builtin (unsigned int fcode, gcall *stmt,
> > aarch64_simd_type_info simd_type
> > = aarch64_simd_types[mem_type];
> > tree elt_ptr_type = build_pointer_type (simd_type.eltype);
> > + elt_ptr_type = build_distinct_type_copy (elt_ptr_type);
> > + TYPE_REF_CAN_ALIAS_ALL (elt_ptr_type) = true;
> > tree zero = build_zero_cst (elt_ptr_type);
> > gimple_seq stmts = NULL;
> > tree base = gimple_convert (&stmts, elt_ptr_type,
> > args[0]);
> > + /* Use element type alignment. */
> > + tree access_type
> > + = build_aligned_type (simd_type.itype,
> > + TYPE_ALIGN (TREE_TYPE (simd_type.itype)));
> > if (stmts)
> > gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
> > new_stmt
> > - = gimple_build_assign (fold_build2 (MEM_REF,
> > - simd_type.itype,
> > - base,
> > - zero), args[1]);
> > + = gimple_build_assign (fold_build2 (MEM_REF, access_type,
> > + base, zero),
> > + args[1]);
> > }
> > break;
> >
> > diff --git a/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c b/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
> > index adb787a8599af23847dd62dcd153d7cfe43dacc0..c1aeb06e74753052c2ee441b361b92148f1b4b0a 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/fmla_intrinsic_1.c
> > @@ -107,10 +107,12 @@ main (int argc, char **argv)
> >
> > /* vfma_lane_f64.
> > vfma_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmadd\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmadd\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 1 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmadd\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 2 { target aarch64_little_endian } } } */
>
> Could you explain this in more detail? What happens for little-endian
> vs. big-endian?
>
> Thanks,
> Richard
>
> >
> > /* vfmaq_lane_f64.
> > vfmaq_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 3 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmla\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 { target aarch64_little_endian } } } */
> >
> >
> > diff --git a/gcc/testsuite/gcc.target/aarch64/fmls_intrinsic_1.c b/gcc/testsuite/gcc.target/aarch64/fmls_intrinsic_1.c
> > index 865def28c3f4d04042ab495d232bb865cabb2b50..3137ea91e809e37de589091e9bbd43bfe4d221a1 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/fmls_intrinsic_1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/fmls_intrinsic_1.c
> > @@ -108,10 +108,12 @@ main (int argc, char **argv)
> >
> > /* vfms_lane_f64.
> > vfms_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmsub\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmsub\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 1 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmsub\\td\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+\, d\[0-9\]+" 2 { target aarch64_little_endian } } } */
> >
> > /* vfmsq_lane_f64.
> > vfmsq_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmls\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmls\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 3 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmls\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 { target aarch64_little_endian } } } */
> >
> >
> > diff --git a/gcc/testsuite/gcc.target/aarch64/fmul_intrinsic_1.c b/gcc/testsuite/gcc.target/aarch64/fmul_intrinsic_1.c
> > index d01095e81c1e45dc1da998aa337ba551b3752ebe..7d4829c40d7042226f2f09fab9fdfa7c3dd211c4 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/fmul_intrinsic_1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/fmul_intrinsic_1.c
> > @@ -107,10 +107,12 @@ main (int argc, char **argv)
> >
> > /* vmul_lane_f64.
> > Vmul_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmul\\td\[0-9\]+, d\[0-9\]+, d\[0-9\]+" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmul\\td\[0-9\]+, d\[0-9\]+, d\[0-9\]+" 1 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmul\\td\[0-9\]+, d\[0-9\]+, d\[0-9\]+" 2 { target aarch64_little_endian } } } */
> >
> > /* vmulq_lane_f64.
> > vmulq_laneq_f64. */
> > -/* { dg-final { scan-assembler-times "fmul\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 } } */
> > +/* { dg-final { scan-assembler-times "fmul\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 3 { target aarch64_big_endian } } } */
> > +/* { dg-final { scan-assembler-times "fmul\\tv\[0-9\]+\.2d, v\[0-9\]+\.2d, v\[0-9\]+\.d\\\[\[0-9\]+\\\]" 2 { target aarch64_little_endian } } } */
> >
> >
next prev parent reply other threads:[~2021-11-05 10:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 9:55 Andre Vieira (lists)
2021-11-04 17:48 ` Richard Sandiford
2021-11-05 10:27 ` Richard Biener [this message]
2021-11-09 9:19 ` Andre Vieira (lists)
2021-11-09 10:47 ` Richard Biener
2021-11-09 12:24 ` [AArch64] Fix big-endian testisms introduced by NEON gimple lowering patch Andre Vieira (lists)
2021-11-09 12:27 ` [AArch64] Fix TBAA information when lowering NEON loads and stores to gimple Andre Vieira (lists)
2021-11-09 15:00 ` Richard Sandiford
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='CAFiYyc3VRHoeuw=y6pCFNUKT2=HAfKG4WvvsHdFMz14F+5MZJQ@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=Kyrylo.Tkachov@arm.com \
--cc=andre.simoesdiasvieira@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.sandiford@arm.com \
/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).