This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, Apr 25, 2012 at 11:29 PM, Olivier Hainque <> 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
>> 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)?


> ?Olivier

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]