From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31211 invoked by alias); 25 Jul 2011 13:22:40 -0000 Received: (qmail 31202 invoked by uid 22791); 25 Jul 2011 13:22:39 -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 mtagate3.uk.ibm.com (HELO mtagate3.uk.ibm.com) (194.196.100.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jul 2011 13:22:25 +0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p6PDMN7l021101 for ; Mon, 25 Jul 2011 13:22:23 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6PDMNAx1925150 for ; Mon, 25 Jul 2011 14:22:23 +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 p6PDMNFd019143 for ; Mon, 25 Jul 2011 07:22:23 -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 p6PDMLDJ019090; Mon, 25 Jul 2011 07:22:22 -0600 Message-Id: <201107251322.p6PDMLDJ019090@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 25 Jul 2011 15:22:21 +0200 Subject: Re: [patch] Fix PR tree-optimization/49771 To: richard.guenther@gmail.com (Richard Guenther) Date: Mon, 25 Jul 2011 13:47: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 01:26:33 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/msg02139.txt.bz2 Richard Guenther wrote: > >>>>>> Well, the back-end assumes a pointer to vector type is always > >>>>>> naturally aligned, and therefore the data it points to can be > >>>>>> accessed via a simple load, with no extra rotate needed. > >>>>> > >>>>> I can't see any use of VECTOR_TYPE in config/spu/, and assuming > >>>>> anything about alignment just because of the kind of the pointer > >>>>> is bogus - the scalar code does a scalar read using that pointer. > >>>>> So the backend better should look at the memory operation, not > >>>>> at the pointer type. That said, I can't find any code that looks > >>>>> suspicious in the spu backend. > >>>>> > >>>>>> It seems what happened here is that somehow, a pointer to int > >>>>>> gets replaced by a pointer to vector, even though their alignment > >>>>>> properties are different. > >>>>> > >>>>> No, they are not. They get replaced if they are value-equivalent > >>>>> in which case they are also alignment-equivalent. But well, the > >>>>> dump snippet wasn't complete and I don't feel like building a > >>>>> SPU cross to verify myself. > > Seems perfectly valid to me. Or well - I suppose we might run into > > the issue that the vectorizer sets alignment data at the wrong spot? > > You can check alignment info when dumping with the -alias flag. > > Building a spu cross now. > > Nope, all perfectly valid. Ah, I guess I see what's happening here. When the SPU back-end is called to expand the load, the source operand is passed as: (mem:SI (reg/f:SI 226 [ vect_pa.9 ]) [2 MEM[base: vect_pa.9_44, offset: 0B]+0 S4 A32]) Now this does say the MEM is only guaranteed to be aligned to 32 bits. However, spu_expand_load then goes and looks at the components of the address in detail, in order to figure out how to best perform the access. In doing so, it looks at the REGNO_POINTER_ALIGN values of the base registers involved in the address. In this case, REGNO_POINTER_ALIGN (226) is set to 128, and therefore the back-end thinks it can use an aligned access after all. Now, the reason why REGNO_POINTER_ALIGN (226) is 128 is that the register is the DECL_RTL for the variable vect_pa.9, and that variable has a pointer-to-vector type (with target alignment 128). When expanding that variable, expand_one_register_var does: if (POINTER_TYPE_P (type)) mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type))); All this is normally completely correct -- a variable of type pointer to vector type *must* hold only properly aligned values. I guess the vectorizer deliberatly loads a (potentially) unaligned value into a vector pointer variable. It then generates a check whether the value is really aligned; and uses it only if so. But if that pointer variable "escapes" into the other branch because DOM thinks it can re-use the value, the REGNO_POINTER_ALIGN value carried for its DECL_RTL register is now incorrect ... Maybe the vectorizer ought to declare that variable with a non-default type alignment setting? Or else, perform the assignment to the variable only *inside* the "if" that checks for correct alignment? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com