From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5290 invoked by alias); 16 Apr 2011 04:35:31 -0000 Received: (qmail 5111 invoked by uid 22791); 16 Apr 2011 04:35:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,TW_QE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 16 Apr 2011 04:34:50 +0000 Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p3G4YnlS012783 for ; Fri, 15 Apr 2011 21:34:49 -0700 Received: from yie12 (yie12.prod.google.com [10.243.66.12]) by kpbe17.cbf.corp.google.com with ESMTP id p3G4YlF1017326 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 21:34:48 -0700 Received: by yie12 with SMTP id 12so1618319yie.13 for ; Fri, 15 Apr 2011 21:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.116.10 with SMTP id t10mr2997710ybm.256.1302928485957; Fri, 15 Apr 2011 21:34:45 -0700 (PDT) Received: by 10.150.200.20 with HTTP; Fri, 15 Apr 2011 21:34:45 -0700 (PDT) In-Reply-To: <1302874496.9717.198.camel@e102346-lin.cambridge.arm.com> References: <4D9EE8C7.6030709@linaro.org> <1302874496.9717.198.camel@e102346-lin.cambridge.arm.com> Date: Sat, 16 Apr 2011 08:12:00 -0000 Message-ID: Subject: Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns, 2/3 From: Carrot Wei To: Richard Earnshaw Cc: Ramana Radhakrishnan , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg01264.txt.bz2 Hi Richard 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. thanks Carrot On Fri, Apr 15, 2011 at 9:34 PM, Richard Earnshaw wrote: > > 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 more >> >> complex, >> >> the attribute length is computed in separate C functions. >> >> > Sorry, no. This is potentially a maintenance pain. It hardcodes altern= atives >> > from a pattern elsewhere in the C file. I don't like doing this unless= 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 constra= ints >> > for everything other than the memory cases (even there we might be abl= e to >> > invent some new constraints) ? >> > >> > Also a note about programming style. There are the helper macros like = 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. =A0Certainly 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. =A0That /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. =A0It *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). =A0Putting 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. > > >