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:25:36 +0100 [thread overview]
Message-ID: <mptttwd659b.fsf@arm.com> (raw)
In-Reply-To: <PAXPR08MB692612373A5D597E6E2270AB93789@PAXPR08MB6926.eurprd08.prod.outlook.com> (Kyrylo Tkachov's message of "Mon, 15 May 2023 14:22:33 +0000")
Kyrylo Tkachov <Kyrylo.Tkachov@arm.com> writes:
>> -----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.
Yeah, but the tests force big-endian, and require a <stdint.h> that
supports big-endian. Newlib supports both endiannesses, but a given
glibc installation doesn't. So the tests will be exercied on *-elf
of any endianness, but will only be exercised on *-linux-gnu for
big-endian.
Richard
next prev parent reply other threads:[~2023-05-15 14:25 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
2023-05-15 14:25 ` Richard Sandiford [this message]
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=mptttwd659b.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).