Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther <richard.guenther@gmail.com>]

On Sat, Jun 11, 2011 at 7:45 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Jun 10, 2011, at 7:20 AM, Richard Guenther wrote:
>> On Fri, 10 Jun 2011, Jason Merrill wrote:
>>
>>> On 06/10/2011 10:03 AM, Richard Guenther wrote:
>>>>>> *((volatile int *)&a[0] + 1)
>>>>>
>>>>> It would be correct to fold it to
>>>>>
>>>>> VIEW_CONVERT_EXPR<volatile int,a[1]>
>>>>
>>>> No, it wouldn't be correct.  It isn't correct to fold it to an array-ref
>>>> that isn't volatile.
>>>
>>> Hmm?  The C expression produces a volatile int lvalue referring to the second
>>> element of a, as does the VIEW_CONVERT_EXPR.  They seem equivalent to me.
>>
>> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example
>> would turn the above to (volatile int) a[1]).
>
> Curious.  We have built up a built-in infrastructure that allows for lvalue register references.  I noticed that for vector types, vectors with different type names but the same in every other respect come out different, and a VIEW_CONVERT_EXPR is placed on it to get the types to match.  Presently I'm treating VIEW_CONVERT_EXPR as an lvalue.  For me not to, I'd need either for the same type to be used, or, for another conversion node to be used that can preserve the lvalueness of registers.
>
> Now, if people want to know why, lvalue for registers, it is to support in/out and output only parameters to built-ins.
>
> Thoughts?

In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avoided
by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it.  Remember that
VIEW_CONVERT_EXPR always conver the full object and are not allowed to
change sizes.

So, do you have an example?

Richard.

(*) Ada uses lvalue component-refs on VIEW_CONVERT_EXPRs of aggregate types.
While I don't like it too much it's probably not too convenient (even
if it is always
possible) to move these to the RHS of assignments.