From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30407 invoked by alias); 13 Jun 2011 10:51:18 -0000 Received: (qmail 30387 invoked by uid 22791); 13 Jun 2011 10:51:17 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Jun 2011 10:51:02 +0000 Received: by wye20 with SMTP id 20so3660979wye.20 for ; Mon, 13 Jun 2011 03:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.197.83 with SMTP id ej19mr4878934wbb.105.1307962261006; Mon, 13 Jun 2011 03:51:01 -0700 (PDT) Received: by 10.227.28.69 with HTTP; Mon, 13 Jun 2011 03:51:00 -0700 (PDT) In-Reply-To: <4DF5396B.6070502@redhat.com> References: <4DEDB98F.6010508@redhat.com> <4DEE2DCF.7020905@redhat.com> <4DEE3484.8030101@redhat.com> <4DF11FBC.3010304@redhat.com> <4DF223D4.3080700@redhat.com> <4DF22656.9050700@redhat.com> <4DF3C98B.6070006@redhat.com> <4DF5396B.6070502@redhat.com> Date: Mon, 13 Jun 2011 12:44:00 -0000 Message-ID: Subject: Re: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))) From: Richard Guenther To: Jason Merrill Cc: Richard Guenther , gcc-patches List , GCC 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-06/txt/msg00967.txt.bz2 On Mon, Jun 13, 2011 at 12:10 AM, Jason Merrill wrote: > On 06/12/2011 06:59 AM, Richard Guenther wrote: >> >> The please provide a specification on what a VIEW_CONVERT_EXPR does >> to type-based alias analysis. > > If the alias set of the VIEW_CONVERT_EXPR type the same as the set for the > operand, ignore it; if it's a subset, handle it like a COMPONENT_REF; > otherwise ignore the operand for TBAA. Handling it as a component-ref would mean adding subsets to the view-convert-expr base. > It seems like get_alias_set currently gets this backwards; it's ignoring > outer COMPONENT_REFs instead of the inner structure. Right, it treats it as if it were an rvalue conversion around an inner lval= ue - everything TBAA related happens on the lvalue, so if you load a view-convert-expr(float_var) the alias set is that of the float. >> Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada >> which uses it for aggregates. > > It also seems to be widely used for vectors, but perhaps that's only for > rvalues. Yes. >> I don't want us to add more lvalue >> VIEW_CONVERT_EXPR cases, especially not for register types. > > Then how do we convert an int lvalue to a volatile int lvalue? By doing *(volatile int *)&int_var. Alternatively you can use a MEM_REF (which sofar isn't created by frontends but only during gimplification) of the form MEM[&int_var, (int *)0] with TREE_THIS_VOLATILE set and a type of volatile int. This is btw. what you can do for your array-ref case as well - just you wouldn't have an array-ref then, but a MEM_REF with a non-zero (but constant) offset (which might be a limitation to you). But I suppose you want the array-ref be folded to a constant eventually? Or why are you not happy with the *(T *)&foo tree? >> /* Represents viewing something of one type as being of a second type. >> =A0 This corresponds to an "Unchecked Conversion" in Ada and roughly to >> =A0 the idiom *(type2 *)&X in C. > > Right, that's why I thought it was an lvalue. "roughly" ;) It's equally roughly (type2)X in C, but that doesn't "work" for aggregate types type2. So we don't have a 1:1 C equivalent of what VIEW_CONVERT_EXPR does. >> =A0 This code may also be used within the LHS of a MODIFY_EXPR > > And this. And the following weasel-wording about "no data motion" for this case. Now, the middle-end shouldn't have an issue dealing with lvalue VIEW_CONVERT_EXPRs, as MEM_REFs are exposing all issues VIEW_CONVERT_EXPR lvalues would do. There is at least the folding to NOP_EXPR and eventually other frontend specific code that might be confused though. And of course there is the TBAA issue, so you have to be careful to not create wrong code - for example folding *(float *)&int_var[5] to VIEW_CONVERT_EXPR(int_var[5]) is wrong. Richard. > Jason >