From: Richard Sandiford <richard.sandiford@arm.com>
To: Kyrylo Tkachov <Kyrylo.Tkachov@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 15:18:26 +0100 [thread overview]
Message-ID: <mpt353x7k5p.fsf@arm.com> (raw)
In-Reply-To: <PAXPR08MB692692782A33DB0869BEF0C593789@PAXPR08MB6926.eurprd08.prod.outlook.com> (Kyrylo Tkachov's message of "Mon, 15 May 2023 15:04:15 +0100")
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.
> 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,
Richard
next prev parent reply other threads:[~2023-05-15 14:18 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 [this message]
2023-05-15 14:22 ` Kyrylo Tkachov
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=mpt353x7k5p.fsf@arm.com \
--to=richard.sandiford@arm.com \
--cc=Kyrylo.Tkachov@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).