On Mon, Jun 13, 2011 at 12:10 AM, Jason Merrill <ja...@redhat.com> 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 lvalue - everything TBAA related happens on the lvalue, so if you load a view-convert-expr<int>(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. >> This corresponds to an "Unchecked Conversion" in Ada and roughly to >> 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. >> 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<float>(int_var[5]) is wrong. Richard. > Jason >
