From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10911 invoked by alias); 2 Jun 2015 09:42:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 10901 invoked by uid 89); 2 Jun 2015 09:42:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: cam-smtp0.cambridge.arm.com Received: from fw-tnat.cambridge.arm.com (HELO cam-smtp0.cambridge.arm.com) (217.140.96.140) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 02 Jun 2015 09:42:35 +0000 Received: from arm.com (e106375-lin.cambridge.arm.com [10.2.207.23]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with ESMTP id t529gVRw025186; Tue, 2 Jun 2015 10:42:31 +0100 Date: Tue, 02 Jun 2015 09:44:00 -0000 From: James Greenhalgh To: Jim Wilson Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH, AARCH64] make stdarg functions work with +nofp Message-ID: <20150602094230.GA4502@arm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00171.txt.bz2 On Sat, May 23, 2015 at 12:24:00AM +0100, Jim Wilson wrote: > The compiler currently ICEs when compiling a stdarg function with > +nofp, as reported in PR 66258. > > The aarch64.md file disables FP instructions using TARGET_FLOAT, which > supports both -mgeneral-regs-only and +nofp. But there is code in > aarch64.c that checks TARGET_GENERAL_REGS_ONLY. This results in FP > instructions when using +nofp, The aarch64.c code needs to use > TARGET_FLOAT instead like the md file already does. > > I can't meaningfully test this with a bootstrap, since the patch has > no effect unless I bootstrap with +nofp, and that will fail as gcc > contains floating point code. > > The testsuite already has multiple stdarg tests, so there is no need > for another one. > > I tested this by verifying I get the same results for some simple > testcasess with and without the patch, with and without using > -mgeneral-regs-only and -mcpu=cortex-a53+nofp. This patch doesn't quite look right to me. The cases you change seem like they should be (TARGET_FLOAT || TARGET_SIMD), rather than just TARGET_FLOAT. In an armv8-a+nofp environment, you still have access to the SIMD registers and instructions (reading between the lines on the bug report, this is almost certainly not what is intended in Grub!). Digging a bit deeper in to the ICE in PR66258, it seems to me that the problematic pattern is "*movti_aarch64": (define_insn "*movti_aarch64" [(set (match_operand:TI 0 "nonimmediate_operand" "=r, *w,r ,*w,r ,Ump,Ump,*w,m") (match_operand:TI 1 "aarch64_movti_operand" " rn,r ,*w,*w,Ump,r ,Z , m,*w"))] "(register_operand (operands[0], TImode) || aarch64_reg_or_zero (operands[1], TImode))" "@ # # # orr\\t%0.16b, %1.16b, %1.16b ldp\\t%0, %H0, %1 stp\\t%1, %H1, %0 stp\\txzr, xzr, %0 ldr\\t%q0, %1 str\\t%q1, %0" [(set_attr "type" "multiple,f_mcr,f_mrc,neon_logic_q, \ load2,store2,store2,f_loadd,f_stored") (set_attr "length" "8,8,8,4,4,4,4,4,4") (set_attr "simd" "*,*,*,yes,*,*,*,*,*") (set_attr "fp" "*,*,*,*,*,*,*,yes,yes")] ) Note that the split alternatives are going to unconditionally create and emit insns which require TARGET_FLOAT, but the fp attribute is not set on those alternatives. Many of the TI mode split patterns could be expressed as a umov from vector registers to general purpose registers for a TARGET_SIMD target. Have you investigated this approach at all? Thanks, James