From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21141 invoked by alias); 25 Jul 2011 15:26:10 -0000 Received: (qmail 21127 invoked by uid 22791); 25 Jul 2011 15:26:08 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.uk.ibm.com (HELO mtagate7.uk.ibm.com) (194.196.100.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 15:25:51 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p6PFPo38023045 for ; Mon, 25 Jul 2011 15:25:50 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6PFPopI2027670 for ; Mon, 25 Jul 2011 16:25:50 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p6PFPnvY031673 for ; Mon, 25 Jul 2011 09:25:49 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p6PFPmiG031656; Mon, 25 Jul 2011 09:25:48 -0600 Message-Id: <201107251525.p6PFPmiG031656@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 25 Jul 2011 17:25:48 +0200 Subject: Re: [patch] Fix PR tree-optimization/49771 To: richard.guenther@gmail.com (Richard Guenther) Date: Mon, 25 Jul 2011 16:12:00 -0000 From: "Ulrich Weigand" Cc: ira.rosen@linaro.org (Ira Rosen), gcc-patches@gcc.gnu.org, patches@linaro.org (Patch Tracking) In-Reply-To: from "Richard Guenther" at Jul 25, 2011 04:43:10 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg02173.txt.bz2 Richard Guenther wrote: > On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote: > > 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. (Maybe this is only true on STRICT_ALIGNMENT > > targets?) 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). Huh, OK. I was not aware of that ... > >> nonzero_bits1 seems to be the only consumer of REGNO_POINTER_ALIGN > >> apart from maybe alpha.c and spu.c. There's also a use in find_reloads_subreg_address, as well as in the i386/predicates.md and arm/arm.md files. > > This means I need to generate a rotate to fix up the value that was > > loaded by the (forced aligned) load instruction. However, 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. If 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? Yes, exactly. > Why not expand this explicitly when you still have the per-SSA name > alignment information around? When would that be? The expansion does happen in the initial expand stage, but I'm getting called from the middle-end via emit_move_insn etc. which already provides me with a MEM ... Can I use REG_ATTRS->decl to get at the register's DECL and use get_pointer_alignment on that? [ On the other hand, don't we have the same problems with reliability of REG_ATTRS that we have with REGNO_POINTER_ALIGN, given e.g. the coalescing you mentioned? ] Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com