From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18988 invoked by alias); 25 Jul 2011 14:43:26 -0000 Received: (qmail 18980 invoked by uid 22791); 25 Jul 2011 14:43:25 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 14:43:10 +0000 Received: by yxi19 with SMTP id 19so2624724yxi.20 for ; Mon, 25 Jul 2011 07:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.51.10 with SMTP id d10mr4391090ybk.330.1311604990200; Mon, 25 Jul 2011 07:43:10 -0700 (PDT) Received: by 10.150.205.2 with HTTP; Mon, 25 Jul 2011 07:43:10 -0700 (PDT) In-Reply-To: <201107251423.p6PENG4Y023392@d06av02.portsmouth.uk.ibm.com> References: <201107251423.p6PENG4Y023392@d06av02.portsmouth.uk.ibm.com> Date: Mon, 25 Jul 2011 14:59:00 -0000 Message-ID: Subject: Re: [patch] Fix PR tree-optimization/49771 From: Richard Guenther To: Ulrich Weigand Cc: Ira Rosen , gcc-patches@gcc.gnu.org, Patch Tracking Content-Type: text/plain; charset=ISO-8859-1 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-07/txt/msg02158.txt.bz2 On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote: > Richard Guenther wrote: > >> > Btw, as pseudos do not have a single def site how can the above >> > ever be correct in the face of coalescing? > > I had always understood this to reflect the simple fact that a > pointer to some type must never hold a value that is not properly > aligned for that type. =A0(Maybe this is only true on STRICT_ALIGNMENT > targets?) =A0 This has always been an important property to generate > good code on SPU ... We do not preserve pointer type casts in the middle-end (anymore). >> > For example on trees we can have >> > >> > =A0p_1 =3D &a; // align 256 >> > =A0p_2 =3D p_1 + 4; // align 32 >> > >> > but we'll coalesce the thing and thus would have to use the weaker >> > alignment of both SSA names. =A0expand_one_register_var expands >> > the decl, not the SSA name, so using get_pointer_alignment on >> > the decl would probably be fine, though also pointless as it always >> > will return 8. >> > >> > At least I don't see any code that would prevent a temporary variable >> > of type int * of being coalesced with a temporary variable of type vec= tor >> > int *. > > I don't really understand the coalesce code, but in the above sample, > the two variables must have the same type, otherwise there'd have to > be a cast somewhere. =A0Does coalesce eliminate casts? No, there is no cast between different pointer types. Information is not attached to types but to real entities. >> > Why should REGNO_POINTER_ALIGN be interesting to anyone? >> > Proper alignment information is (should be) attached to every >> > MEM already. >> >> nonzero_bits1 seems to be the only consumer of REGNO_POINTER_ALIGN >> apart from maybe alpha.c and spu.c. >> >> We should simply kill REGNO_POINTER_ALIGN IMHO. > > On the SPU at least, REGNO_POINTER_ALIGN carries additional information > over just the MEM alignment. =A0Say, I'm getting a MEM the form > (mem (plus (reg X) (reg Y))), and the MEM is aligned to 32 bits. > > This means I need to generate a rotate to fix up the value that was > loaded by the (forced aligned) load instruction. =A0However, the form > of this rotate can be simpler if I know that e.g. reg X is always > guaranteed to be 128-bits aligned and only reg Y introduces the > potential misalignment. =A0If on the other hand neither of the base > registers is guaranteed to be 128-bit aligned, I need to generate > more complex rotate code ... Because then you need the value of X + Y instead of just picking either? Why not expand this explicitly when you still have the per-SSA name alignment information around? > I understand this may also be important on other platforms, e.g. > to choose which register to use as base and which as index in a > memory operation ... Well, we still have REG_POINTER. Richard. > Bye, > Ulrich > > -- > =A0Dr. Ulrich Weigand > =A0GNU Toolchain for Linux on System z and Cell BE > =A0Ulrich.Weigand@de.ibm.com >