From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 5A5063857736 for ; Mon, 15 May 2023 14:25:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A5063857736 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA58B2F4; Mon, 15 May 2023 07:26:22 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 93C313F840; Mon, 15 May 2023 07:25:37 -0700 (PDT) From: Richard Sandiford To: Kyrylo Tkachov Mail-Followup-To: Kyrylo Tkachov ,"gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" Subject: Re: [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics References: <20230509064831.1651327-1-richard.sandiford@arm.com> <20230509064831.1651327-3-richard.sandiford@arm.com> Date: Mon, 15 May 2023 15:25:36 +0100 In-Reply-To: (Kyrylo Tkachov's message of "Mon, 15 May 2023 14:22:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-23.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Kyrylo Tkachov writes: >> -----Original Message----- >> From: Richard Sandiford >> Sent: Monday, May 15, 2023 3:18 PM >> To: Kyrylo Tkachov >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH 2/6] aarch64: Allow moves after tied-register intrinsics >> >> Kyrylo Tkachov writes: >> > Hi Richard, >> > >> >> -----Original Message----- >> >> From: 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 >> >> 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 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