From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22374 invoked by alias); 18 Apr 2011 13:34:03 -0000 Received: (qmail 22041 invoked by uid 22791); 18 Apr 2011 13:34:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_QE 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 13:33:19 +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 14:33:16 +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 14:33:15 +0100 Subject: Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns, 2/3 From: Richard Earnshaw To: Carrot Wei Cc: Ramana Radhakrishnan , gcc-patches@gcc.gnu.org In-Reply-To: References: <4D9EE8C7.6030709@linaro.org> <1302874496.9717.198.camel@e102346-lin.cambridge.arm.com> Date: Mon, 18 Apr 2011 14:05:00 -0000 Message-Id: <1303133594.17819.7.camel@e102346-lin.cambridge.arm.com> Mime-Version: 1.0 X-MC-Unique: 111041814331604201 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/msg01386.txt.bz2 On Sat, 2011-04-16 at 12:34 +0800, Carrot Wei wrote: > Hi Richard >=20 > Thank you for the detailed explanation. It sounds like an inherent > difficulty of rtl passes. Then the only opportunity is ldrb/strb > instructions because they never affect cc registers. There are also some comparison operations that are also known to be 2 bytes (because they are known to set the condition codes). But yes, the scope here is quite limited. R. >=20 > thanks > Carrot >=20 > On Fri, Apr 15, 2011 at 9:34 PM, Richard Earnshaw wrot= e: > > > > On Thu, 2011-04-14 at 21:19 +0800, Carrot Wei wrote: > >> On Fri, Apr 8, 2011 at 6:51 PM, Ramana Radhakrishnan > >> wrote: > >> > On 08/04/11 10:57, Carrot Wei wrote: > >> >> > >> >> Hi > >> >> > >> >> This is the second part of the fixing for > >> >> > >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D47855 > >> >> > >> >> This patch contains the length computation for insn patterns > >> >> "*arm_movqi_insn" > >> >> and "*arm_addsi3". Since the alternatives and encodings are much mo= re > >> >> complex, > >> >> the attribute length is computed in separate C functions. > >> > >> > Sorry, no. This is potentially a maintenance pain. It hardcodes alte= rnatives > >> > from a pattern elsewhere in the C file. I don't like doing this unle= ss we > >> > have to with the sync primitives or with push_multi. In this case I'= m not > >> > convinced we need such functions in the .c file. > >> > > >> > Why can't we use the "enabled" attribute here with appropriate const= raints > >> > for everything other than the memory cases (even there we might be a= ble to > >> > invent some new constraints) ? > >> > > >> > Also a note about programming style. There are the helper macros lik= e REG_P, > >> > CONST_INT_P and MEM_P which remove the necessity for checks like > >> > > >> > GET_CODE (x) =3D=3D y where y E { REG, CONST_INT, MEM} > >> > >> Hi Ramana > >> > >> As you suggested I created several new constraints, and use the > >> "enabled" attribute to split the current alternatives in this new > >> patch. It has been tested on arm qemu without regression. > >> > >> thanks > >> Carrot > > > > > > Sorry, I don't think this approach can work. Certainly not with the way > > the compiler currently works, and especially for mov and add insns. > > > > These instructions are only 2 bytes long if either: > > 1) They clobber the condition code register or > > 2) They occur inside an IT block. > > > > We can't tell either of these from the pattern, so you're > > underestimating the length of the instruction in some circumstances by > > claiming that they are only 2 bytes long. That /will/ lead to broken > > code someday. > > > > We can't add potential clobbers to mov and add patterns because that > > will break reload which relies on these patterns being simple-set insns > > with no added baggage. It *might* be possible to add clobbers to other > > operations, but that will then most-likely upset instruction scheduling > > (I think the scheduler treats two insns that clobber the same hard reg > > as being strongly ordered). Putting in the clobber too early will > > certainly affect cond-exec generation. > > > > In short, I'm not aware of a simple way to address this problem so that > > we get accurate length information, but minimal impact on other passes > > in the compiler. > > > > R. > > > > > > >=20