Re: fix incorrect SRA transformation on non-integral VIEW_CONVERT argument

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Apr 25, 2012 at 11:29 PM, Olivier Hainque <hainque@adacore.com> wrote:
> Thanks for your feedback Richard,
>
> On Apr 25, 2012, at 16:16 , Richard Guenther wrote:
>> I think much better would be to simply disallow any toplevel
>> VIEW_CONVERT_EXPR of BLKmode,
>
>> Does that fix your problems, too? ?If so I prefer that.
>
> ?Hmm, I think that this would fix the particular testscase at
> ?hand but not quite the underlying issue I was aiming at.
>
> ?The basic problem I am trying to address is SRA turning
> ?VCE (<some access>) into VCE (<scalar>) where the replacement
> ?<scalar> is of a different size than <some access>.
>
> ?The idea of locating the check in create_access is that
> ?this is where the <access> size is computed.
>
> ?I'm pretty sure that excluding just on BLKmode for
> ?TYPE(<access>) doesn't catch them all.
>
> ?In particular, I'm pretty sure that we can get component
> ?refs of integral modes that access a smaller range of bits
> ?than what the mode conveys. It is common with packing or
> ?rep clauses in Ada.

Yeah, well - the tree verification code in tree-cfg.c is not enforcing
any constraints here and the docs are not clear either.  My view is
that we don't want the size of the VIEW_CONVERT_EXPR differ
from the size of its operand - you should use a BIT_FIELD_REF
or a MEM_REF for that (yes, VIEW_CONVERT_EXPRs could be
removed or treated as short-cut for a BIT_FIELD_REF that covers
the whole object).

> ?I'll see if I can come up with a case tomorrow.
>
> ?I'm actually also slightly confused by the processing of
> ?VCE inputs in SRA, as VCE (<composite>) and VCE (<scalar>)
> ?are not supposed to result in the same outcome for identical
> ?bit size and patterns on big endian. But I might just still
> ?be missing something here.

Well, it's not clear to me either what the semantics of a VIEW_CONVERT_EXPR
is when you apply it to memory and the result is not of the same size as
the operand.  Naively a VIEW_CONVERT_EXPR is *(T *)&op?  Then a
VIEW_CONVERT_EXPR <T, op> would be the same as
MEM_REF <T, &op, (T' *)0> with the advantage that for the MEM_REF you
can specify the alias set that is supposed to be in effect.  Similar
it would be the same as BIT_FIELD_REF <T, &op, sizeof (T) * BITS_PER_UNIT, 0>.

Can you formally relate those three representations and tell me why
VIEW_CONVERT_EXPR is useful (not only convenient because of less operands)
to use on lvalues (thus memory, compared to registers or constants)?

Thanks,
Richard.

> ?Olivier
>