Message ID | 20211227190530.3136549-34-gnu@danielengel.com |
---|---|
State | Superseded |
Delegated to: | Richard Earnshaw |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 71F64385800F for <patchwork@sourceware.org>; Mon, 27 Dec 2021 19:24:12 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by sourceware.org (Postfix) with ESMTPS id 59F11385842E for <gcc-patches@gcc.gnu.org>; Mon, 27 Dec 2021 19:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 59F11385842E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=danielengel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=danielengel.com Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0DCE632009BE; Mon, 27 Dec 2021 14:12:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 27 Dec 2021 14:12:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielengel.com; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm1; bh=iZRBoBgEivGVz MRFEtIzkCj6RKreModR0zZpbwKfGNw=; b=k6cF/+yYoEbDOMWEzfnuY4afKemam S5qG9KavWhPsq3BHdNS5epFm31Xoh9X+2fCUrK3Zqq5dHXHOn4N09I/DxyVSYp4H EBwVIDQ2CJusUwpgMCdH/QnBWxPXVMX8wZjgXS4lsIiXlOGZaguNXdMsbto1azaQ dtvc/6v1TdyknnSy1n4rS1esJxzyj32sAaGqg2Gnvwm/TwfY+jqiws1EPzot6YjU 0LMMvUf5jEjBQLuMFF7FGDPRJdU34ZveboNgMh7GVo+PQQf4IyONk1/YcE1QDEf0 4xA4nUgwtyp42I0vVVMc2tfky7VWG48yG2nt9Tt9/hyQnRSooWC9xCgnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=iZRBoBgEivGVzMRFEtIzkCj6RKreModR0zZpbwKfGNw=; b=KA2pq9IQ yRIyp7FoknQ12hzqkOSDaWoG8A92WngWRbmuMIOpK8DEtP5T03dvVfHVH69G9snF GsInhw+1W+meUZsu4gp43u3h0HUJJfF3dgskQB0X1uMkkH8ViOsbgSGHpxWkfYcd 3FBmC0bN7X6OpKXL2D/0oaPa4bR9bDjnQqn5DPhPSLPGZDI7K/D8CmvDnW64kYPj +tTBE7XkvkwkwymWGA+4IGXS/R8NkwFhVeNFWv65YH2oOv9Ac8j+L0C9/kaHnFrN lpfOW6EsYOLlG9SsTspuyaOJgKF0uEFMnfMs6boEAQNOZG46gVNWsDJUnpPaRICQ 0sAL03oP9iqRew== X-ME-Sender: <xms:CBDKYZ4DYVkXPt_6QFZYTIEbpRo0rARNgkTA3yAR1Kb4Y3yyg6F7PQ> <xme:CBDKYW6aLNlwB54oQUZH2RDhj-pzc8ct1yvdPKSEZjtzy74eAbBo0eCQUZVUJBJR6 Btu8c4IsK9oJQ> X-ME-Received: <xmr:CBDKYQfthENP1gkZFHud8e98bgmXcgIfEXkRC3p0GOwW1RyYjllK3oI1KAzuAJnQVd65AcpS4PE-GEqxmaIjqZFixIHuMX1mp-LD_oFt-FCaPDVW8c3S> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddujedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomhepffgrnhhi vghlucfgnhhgvghluceoghhnuhesuggrnhhivghlvghnghgvlhdrtghomheqnecuggftrf grthhtvghrnhepkeefudfgffekheelhedtlefhkeekjefhheetheefhffftefhiedvuefh ieejtdegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epghhnuhesuggrnhhivghlvghnghgvlhdrtghomh X-ME-Proxy: <xmx:CBDKYSKi5AUWBMUNhETAJbL6m5JUkF8O_73Ms7LSS01eL-M-4Mz-YQ> <xmx:CBDKYdJYnxsjX1CC8JeRMqgUP8RjUAWkFYnJ7JHU2pVkJx36OPi48Q> <xmx:CBDKYbwZJGs-NIg766jAyIcsfgc1-lMxoRShC8FVRYIz6PhYdtwddg> <xmx:CBDKYUXu2YgAN3KBa5GGjBuXUWLTCO0voroxR-xvrW5iqNITY1Gy6w> Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Dec 2021 14:12:07 -0500 (EST) Received: from ubuntu.lorien.danielengel.com (ubuntu.lorien.danielengel.com [10.0.0.96]) by sendmail.lorien.danielengel.com (8.15.2/8.15.2) with ESMTP id 1BRJC6xi061106; Mon, 27 Dec 2021 11:12:06 -0800 (PST) (envelope-from gnu@danielengel.com) From: Daniel Engel <gnu@danielengel.com> To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>, gcc-patches@gcc.gnu.org Subject: [PATCH v6 33/34] Drop single-precision Thumb-1 soft-float functions Date: Mon, 27 Dec 2021 11:05:29 -0800 Message-Id: <20211227190530.3136549-34-gnu@danielengel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211227190530.3136549-1-gnu@danielengel.com> References: <20211227190530.3136549-1-gnu@danielengel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Cc: Daniel Engel <gnu@danielengel.com>, Christophe Lyon <christophe.lyon@linaro.org> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
libgcc: Thumb-1 Floating-Point Assembly for Cortex M0
|
|
Commit Message
Daniel Engel
Dec. 27, 2021, 7:05 p.m. UTC
With the complete CM0 library integrated, regression testing showed new failures with the message "compilation failed to produce executable": gcc.dg/fixed-point/convert-float-1.c gcc.dg/fixed-point/convert-float-3.c gcc.dg/fixed-point/convert-sat.c Investigating, this appears to be caused by the linker. I can't find a comprehensive linker specification to claim this is actually a bug, but it certainly doesn't match my expectations. Investigating, I found issues with the link order of these symbols: * __aeabi_fmul() * __aeabi_f2d() * __aeabi_f2iz() Specifically, I expect the linker to import the _first_ definition of any symbol. This is the basic behavior that allows the soft-float library to supply missing symbols on architectures without optimized routines. Comparing the v6-m multilib with the default, I see symbol exports for all of the affect symbols: gcc-obj/gcc/libgcc.a: // assembly routines _arm_mulsf3.o: 00000000 W __aeabi_fmul 00000000 W __mulsf3 _arm_addsubdf3.o: 00000368 T __aeabi_f2d 00000368 T __extendsfdf2 _arm_fixsfsi.o: 00000000 T __aeabi_f2iz 00000000 T __fixsfsi mulsf3.o: <empty> fixsfsi.o: <empty> extendsfdf2.o.o: <empty> gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a: // assembly routines _arm_mulsf3.o: 00000000 T __aeabi_fmul U __fp_assemble U __fp_exception U __fp_infinity U __fp_zero 00000000 T __mulsf3 U __umulsidi3 _arm_fixsfsi.o: 00000000 T __aeabi_f2iz 00000000 T __fixsfsi 00000002 T __internal_f2iz _arm_f2d.o: 00000000 T __aeabi_f2d 00000000 T __extendsfdf2 U __fp_normalize2 // soft-float library mulsf3.o: 00000000 T __aeabi_fmul fixsfsi.o: 00000000 T __aeabi_f2iz extendsfdf2.o: 00000000 T __aeabi_f2d Given the order of the archive file, I expect the linker to import the affected functions from the _arm_* archive elements. For "convert-sat.c", all is well with -march=armv7-m. ... (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_muldf3.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_mulsf3.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_cmpsf2.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixsfsi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixunssfsi.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_addsubdf3.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixdfsi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixunsdfsi.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixsfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixunsdfdi.o ... However, with -march=armv6s-m, the linker imports these symbols from the soft- float library. (NOTE: The CM0 library only implements single-precision float operations, so imports from muldf3.o, fixdfsi.o, etc are expected.) ... ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)mulsf3.o ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixsfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)muldf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixdfsi.o ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)extendsfdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_clzsi2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmpge.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmple.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixsfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunssfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)eqdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)gedf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)ledf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)subdf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)floatunsidf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpsf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixsfsi.o ... It seems that the order in which the linker resolves symbols matters. In the affected test cases, the linker begins searching for fixed-point function symbols first: _subQQ.o, _cmpQQ.o, etc. The fixed-point archive elements appear after the _arm_* archive elements, so the initial definitions of the floating point functions are discarded. However, the fixed-point functions contain unresolved symbol references which the linker registers progressively. Given that the default libgcc.a does not build the soft-point library [1], the linker cannot import any floating point objects until the second pass. However, when v6-m/nofp/libgcc.a _does_ include the soft-point library, the linker proceeds to import some floating point objects during the first pass. To test this theory, add explicit symbol references to convert-sat.c: --- a/gcc/testsuite/gcc.dg/fixed-point/convert-sat.c +++ b/gcc/testsuite/gcc.dg/fixed-point/convert-sat.c @@ -11,6 +11,12 @@ extern void abort (void); int main () { + volatile float a = 1.0; + volatile float b = 2.0; + volatile float c = a * b; + volatile double d = a; + volatile int e = a; + SAT_CONV1 (short _Accum, hk); SAT_CONV1 (_Accum, k); SAT_CONV1 (long _Accum, lk); Afterwards, the linker imports the expected symbols: ... ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_mulsf3.o ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_muldi3.o ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixsfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_f2d.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_exceptionf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_assemblef.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_normalizef.o ... (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)muldf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_clzsi2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixunssfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmpge.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmple.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixsfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)eqdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)gedf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)ledf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)subdf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)floatunsidf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpsf2.o ... At a minimum this behavior results in the use of non-preferred code in an affected application. However, as long as each object exports a single entry point, this does not automatically result in a build failure. Indeed, in the case of __aeabi_fmul() and __aeabi_f2d(), all references seem to resolve uniformly in favor of the soft-float library. The first pass that imports the soft-float version of __aeabi_f2iz() also succeeds. However, the first pass fails to find __aeabi_f2uiz(), since the soft-float library does not implement this variant. So, this symbol remains undefined until the second pass. However, the assembly version of __aeabi_f2uiz() the linker finds happens to be implemented as a branch to __internal_f2iz() [2]. But the linker, importing __internal_f2iz(), also finds the main entry point __aeabi_f2iz(). And, since __aeabi_f2iz() was already found in the soft-float library, the linker throws an error. The solution is two-fold. First, the assembly routines have separately been made robust against this potential error condition (by weakening and splitting symbols). Second, this commit to block single-precision functions from the soft-float library makes it impossible for the linker to select a non-preferred version. Two duplicate symbols remain (extendsfdf2) and (truncdfsf2), but the situation is much improved. [1] softfp_wrap_start = "#if !__ARM_ARCH_ISA_ARM && __ARM_ARCH_ISA_THUMB == 1" [2] (These operations share a substantial portion of their code path, so this choice leads to a size reduction in programs that use both functions.) gcc/libgcc/ChangeLog: 2021-01-13 Daniel Engel <gnu@danielengel.com> * config/arm/t-softfp (softfp_float_modes): Added as "df". --- libgcc/config/arm/t-softfp | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/libgcc/config/arm/t-softfp b/libgcc/config/arm/t-softfp index 554ec9bc47b..bd6a4642e5f 100644 --- a/libgcc/config/arm/t-softfp +++ b/libgcc/config/arm/t-softfp @@ -1,2 +1,4 @@ softfp_wrap_start := '\#if !__ARM_ARCH_ISA_ARM && __ARM_ARCH_ISA_THUMB == 1' softfp_wrap_end := '\#endif' +softfp_float_modes := df +