From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22353 invoked by alias); 18 Apr 2011 09:39:15 -0000 Received: (qmail 22344 invoked by uid 22791); 18 Apr 2011 09:39:14 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Mon, 18 Apr 2011 09:38:41 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 18 Apr 2011 10:38:38 +0100 Received: from [10.1.67.34] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Apr 2011 10:38:36 +0100 Subject: Re: PR target/46329: Reject Neon structure constants From: Richard Earnshaw To: Richard Sandiford Cc: gcc-patches@gcc.gnu.org, patches@linaro.org In-Reply-To: References: Date: Mon, 18 Apr 2011 10:40:00 -0000 Message-Id: <1303119516.15603.6.camel@e102346-lin.cambridge.arm.com> Mime-Version: 1.0 X-MC-Unique: 111041810383813301 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2011-04/txt/msg01365.txt.bz2 On Mon, 2011-04-04 at 11:34 +0100, Richard Sandiford wrote: > This patch fixed PR target/46329, which is a problem that occurs > when trying to reload: >=20 > (set (reg:OI foo) (const_int 0)) >=20 > There is no move alternative for moving constants directly into large > numbers of VFPs, and it probably isn't going to be sensible to do that > for all constants, even if proper support for large-int constants is > implemented in future. It also isn't feasible to use the normal ARM > constant pool, since the vldN and vstN instructions don't support the > required addressing modes. >=20 > At the moment, reload instead tries to load the constant through GPRs, > having been told to do so by coproc_secondary_reload_class. > That doesn't work either because there aren't enough (consecutive) > GPRs to go around. >=20 > Instead, this patch forces constants to the target-independent > constant pool. Even if we do optimise the handling for "easy" > constants like 0 in future, I think we'd still need this code > for the more complicated cases. >=20 > An alternative would have been to make preferred_reload_class > return NO_REGS, but we should get better code by exposing the > restriction earlier. >=20 > The patch applies on top of: >=20 > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00194.html > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00195.html >=20 > Tested on arm-linux-gnueabi. OK to install? >=20 > Richard >=20 I'm uncomfortable about this. Generally the ARM port doesn't work well with the target-independent constant pool and it's better to assert that this is empty when it comes to final assembly generation. Can you clarify by way of example how this patch is working please (ie some sample output). R.