From: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
To: Richard Sandiford <Richard.Sandiford@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: RE: [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics
Date: Mon, 15 May 2023 14:22:33 +0000 [thread overview]
Message-ID: <PAXPR08MB692612373A5D597E6E2270AB93789@PAXPR08MB6926.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <mpt353x7k5p.fsf@arm.com>
> -----Original Message-----
> From: Richard Sandiford <richard.sandiford@arm.com>
> Sent: Monday, May 15, 2023 3:18 PM
> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics
>
> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes:
> > Hi Richard,
> >
> >> -----Original Message-----
> >> From: Gcc-patches <gcc-patches-
> >> bounces+kyrylo.tkachov=arm.com@gcc.gnu.org> On Behalf Of Richard
> >> Sandiford via Gcc-patches
> >> Sent: Tuesday, May 9, 2023 7:48 AM
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Richard Sandiford <Richard.Sandiford@arm.com>
> >> Subject: [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics
> >>
> >> Some ACLE intrinsics map to instructions that tie the output
> >> operand to an input operand. If all the operands are allocated
> >> to different registers, and if MOVPRFX can't be used, we will need
> >> a move either before the instruction or after it. Many tests only
> >> matched the "before" case; this patch makes them accept the "after"
> >> case too.
> >>
> >> gcc/testsuite/
> >> * gcc.target/aarch64/advsimd-intrinsics/bfcvtnq2-untied.c: Allow
> >> moves to occur after the intrinsic instruction, rather than requiring
> >> them to happen before.
> >> * gcc.target/aarch64/advsimd-intrinsics/bfdot-1.c: Likewise.
> >> * gcc.target/aarch64/advsimd-intrinsics/vdot-3-1.c: Likewise.
> >
> > I'm seeing some dot-product intrinsics failures:
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O1 check-function-
> bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O1 check-function-
> bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O2 check-function-
> bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O2 check-function-
> bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O2 -flto -fno-use-
> linker-plugin -flto-partition=none check-function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O2 -flto -fno-use-
> linker-plugin -flto-partition=none check-function-bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O3 -g check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -O3 -g check-
> function-bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -Og -g check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -Og -g check-
> function-bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -Os check-function-
> bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c -Os check-function-
> bodies ufooq_lane_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O1 check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O1 check-
> function-bodies ufooq_laneq_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O2 check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O2 check-
> function-bodies ufooq_laneq_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O2 -flto -fno-use-
> linker-plugin -flto-partition=none check-function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O2 -flto -fno-use-
> linker-plugin -flto-partition=none check-function-bodies
> ufooq_laneq_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O3 -g check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -O3 -g check-
> function-bodies ufooq_laneq_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -Og -g check-
> function-bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -Og -g check-
> function-bodies ufooq_laneq_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -Os check-function-
> bodies ufoo_untied
> > FAIL: gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c -Os check-function-
> bodies ufooq_laneq_untied
>
> Ugh. Big-endian. Hadn't thought about that being an issue.
> Was testing natively on little-endian aarch64-linux-gnu and
> didn't see these.
FWIW this is on a little-endian aarch64-none-elf configuration.
Maybe some defaults are different on bare-metal from Linux...
>
> > From a quick inspection it looks like it's just an alternative regalloc that
> moves the mov + dot instructions around, similar to what you fixed in bfdot-
> 2.c and vdot-3-2.c.
> > I guess they need a similar adjustment?
>
> Yeah, will fix.
Thanks!
Kyrill
>
> Thanks,
> Richard
next prev parent reply other threads:[~2023-05-15 14:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 6:48 [PATCH 0/6] aarch64: Avoid hard-coding specific register allocations Richard Sandiford
2023-05-09 6:48 ` [PATCH 1/6] aarch64: Fix move-after-intrinsic function-body tests Richard Sandiford
2023-05-09 6:48 ` [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics Richard Sandiford
2023-05-15 14:04 ` Kyrylo Tkachov
2023-05-15 14:18 ` Richard Sandiford
2023-05-15 14:22 ` Kyrylo Tkachov [this message]
2023-05-15 14:25 ` Richard Sandiford
2023-05-09 6:48 ` [PATCH 3/6] aarch64: Relax ordering requirements in SVE dup tests Richard Sandiford
2023-05-09 6:48 ` [PATCH 4/6] aarch64: Relax predicate register matches Richard Sandiford
2023-05-09 6:48 ` [PATCH 5/6] aarch64: Relax FP/vector " Richard Sandiford
2023-05-09 6:48 ` [PATCH 6/6] aarch64: Avoid hard-coding specific register allocations 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=PAXPR08MB692612373A5D597E6E2270AB93789@PAXPR08MB6926.eurprd08.prod.outlook.com \
--to=kyrylo.tkachov@arm.com \
--cc=Richard.Sandiford@arm.com \
--cc=gcc-patches@gcc.gnu.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).