This is the mail archive of the gcc-patches@gcc.gnu.org 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


Hello Richard,

Thanks for the constructive exchange :-)

On Apr 26, 2012, at 10:48 , Richard Guenther wrote:
>>  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

 I agree the current situation is not ideal.

 What you suggest corresponds to what is currently documented
 (difference => undefined behavior), but I'm pretty sure that the Ada compiler
 relies on some cases to behave in some specific manner. For tagged types
 IIRC.

 It would certainly be nice to get rid of this discrepancy at some point.

 The issue I was trying to address was a bit different: SRA changing the
 VCE argument "access" size, which seems incorrect regardless of the source
 destination size consistency. I can see how they are connected though and
 will see if I can come up with a different approach.

[...]

> 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)?

 I have ideas on how they are supposed to relate (corresponding to your
 intuitive understanding, what is documented), but MEM_REF and BIT_FIELD_REF
 were introduced much more recently though, so I'm pretty sure that there are
 details that escape me.

 


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