https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-03-10
CC| |law at redhat dot com
Ever confirmed|0 |1
--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
AFAICT the coalescing code is working as expected here. Working with
r226900...
So, the only real statement of interest is:
# iftmp.0_1 = PHI <iftmp.0_18(3), new_line_9(2)>
Which results in the following partition map:
Partition 0 (iftmp.0_1 - 1 )
Partition 1 (line_7(D) - 7 )
Partition 2 (iftmp.0_18 - 18 )
And the following coalesce list:
Coalesce list: (1)iftmp.0_1 & (18)iftmp.0_18 [map: 0, 2] : Success -> 0
Note that new_line_9 isn't ever processed. Which is a bit odd to say the
least. Moving to r226901 we have:
Partition 0 (iftmp.0_1 - 1 )
Partition 1 (line_7(D) - 7 )
Partition 2 (new_line_9 - 9 )
Partition 3 (iftmp.0_18 - 18 )
Coalesce list: (1)iftmp.0_1 & (9)new_line_9 [map: 0, 2] : Success -> 0
Coalesce list: (1)iftmp.0_1 & (18)iftmp.0_18 [map: 0, 3] : Success -> 0
Note that we coalesced new_line_9 into the same partition as iftmp.0_{1,18}.
That seems valid given their use in the PHI and my quick review of the
conflicts.
So looking at the actual expansion r226900 will emit a copy from new_line_9
into iftmp.0_{1,18}. That's a result of r226900 not coalescing the objects.
So AFAICT this isn't a coalescing issue, at least not at the gimple->rtl
expansion point.
