http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org
|gnu.org |
--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-11-23
16:01:37 UTC ---
What happens in SRA is this. This a part of the dump before SRA
(ealias):
<bb 2>:
D.2127_5 = *a_1(D);
if (D.2127_5 > 0)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
D.2126_6 = D.2127_5 <= 45;
/* In the following statement SRA notices a logical access
to __result_master.1.f2. */
__result_master.1.f2.e2 = D.2126_6;
goto <bb 5>;
<bb 4>:
/* In the following statement SRA notices a complex access
to __result_master.1.f2. If a scalar type access has a scalar type
sub-access, they cannot be made into replacements. */
__result_master.1.f2.f2 = __complex__ (4.5e+1, 0.0);
<bb 5>:
/* However, before SRA figures that out, it propagates the logical
sub-accesses across the following aggregate assignment in order to
facilitate pseudo copy propagation of aggregates. Thus, D.2125 gets an
artificial logical sub-access which is a child of an aggregate and qualifies
for replacement creation. And that's why the weird logical variable gets
there. */
D.2125 = __result_master.1.f2;
__result_master.1.f2 ={v} {CLOBBER};
__result = D.2125;
D.2056_2 = __result.f2;
}
We should not do propagation of sub-accesses of scalar accesses because
that's never profitable and it would also fix this testcase.
However, I'm afraid that if we encapsulated
__result_master.1.f2.f2 = __complex__ (4.5e+1, 0.0);
into the union type and moved the last two statements of the function
into a different function, we would get the logical replacements of
__result_master.1.f2 and D.2125 again and might incur the same problems
(depending on whether FRE would be able to look through this).
SRA on unions and type-conversions is tough.
