[patch] Fix PR tree-optimization/51624

Richard Guenther richard.guenther@gmail.com
Tue Jan 3 10:36:00 GMT 2012


On Tue, Jan 3, 2012 at 11:16 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> If you have nested structure types that are TYPE_STRUCTURAL_EQUALITY
>> then they have TYPE_CANONICAL == NULL_TREE and types_compatible_p
>> will return false (it ICEd in previous releases I believe) and thus you
>> won't stop attaching COMPONENT_REFs.
>>
>> So the fix isn't complete.
>
> OK, I see.  Then the only way out I can think of is to stop going up the chain
> of COMPONENT_REFs as soon as the offset becomes negative.

Yeah, that sounds like a better solution.

>> > MEM_REF is nice, but SRA should stop rewriting component accesses that it
>> > doesn't scalarize, this is waste of time and memory, and introduces bugs.
>>
>> I agree - I didn't know it does that.  Do you have an example?
>
> The very problem I'm debugging:
>
>  SR.37_109 = it.nam;
>  SR.38_110 = it.typ;
>
> What's the point in generating MEM_REF to access a simple component?  Of
> course, this is somewhat hidden since the tree pretty-printer is clever
> (evil?) enough to print
>
>  <COMPONENT_REF <MEM_REF <ADDR_EXPR <VAR_DECL it>>>, nam>
>
> as
>
>  it.nam
>
> but this wastes 2 tree nodes.

Ah.  Well - the point is that SRA analyzes accesses using a type, offset, size
triple, thus it handles scalarizing unions well even if multiple fields are used
from it.  But it indeed can as well use the original access tree if it does not
change the access (by decomposing it, for example).  That's probably
a worthwhile change anyway - Martin?

Thanks,
Richard.

> --
> Eric Botcazou



More information about the Gcc-patches mailing list