This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR 23551: why should we coalesce inlined variables?
On Jul 9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
> On Mon, 2007-07-09 at 12:01 -0300, Alexandre Oliva wrote:
>> On Jul 9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
>>
>> > The only optimization I know of that cares about the base name is out
>> > of ssa when it builds conflict graphs for coalescing,
>>
>> The point I was getting at is that there's no good reason to do
>> coalescing. Generating RTL with one pseudo per SSA is quite natural,
>> and then register allocation will take care of all the coalescing,
> You are kidding right?
Not in principle, no. The problems of coalescing SSA variables and
optimizing away copies for PHI nodes appear to be equivalent to those
of register allocation. I don't see good reasons to solve the same
problems twice in the translation of the same function.
> You better write us a new register allocator before doing that!
Probably. Maybe it's worth pointing out that this bit about not
performing these SSA transformations is unrelated to my current
project of improving debug info, it's just a plan to improve overall
optimization.
> Besides, the coalescing the out-off-ssa does is PHI-NODE coalescing
> primarily.
Yup.
> that is a TON of extra copies you will then have to issue, and then
> remove.
Or have the register allocator take PHI notes in BB entry points into
account, inserting copies in case it doesn't manage to assign both
pseudos to the same location. Which, if SSA coalescing can do, then
so can a good register allocator.
> we are by no means in any state to allow those kinds of unnecceary
> copies through.
I realize that. Please don't get the impression that long-term pipe
dreams are in any way related with the debug info project.
> with SSA, you better think hard about PHIs, they are key.
Yup. But then, SSA makes things over basic blocks work like magic, so
I'm working first on getting stuff right inside basic blocks, to then
figure out how the PHI function handling ought to look like.
> foo_1 =
> bar_2 =
> bar_4 - bar_2 + 1
> foo_5 = bar_2 - 1
> when we coalesced foo_3 and bar_2, to bar_2, we update the debug
> list for bar_2 to be 'foo' and 'bar'. then in out of ssa, we issue
> the debug info for both 'foo' and 'bar' to match the range of bar_2.
Do you realize that debug info will be wrong for foo in this case,
because it will appear to hold the same value as bar_2 starting at the
assignment to bar_2, while it should still hold the foo_1 value? This
is precisely one of the problems I'm trying to address.
> this is at a cost. NOW the live range of bar_2 goes past bar_4, so NOW
> bar_2 and bar_4 have to be different variables and cannot be coalesced
> together to 'bar' anymore. So we are now using a third variable
> foo =
> bar =
> bar.1 = bar + 1
> foo = bar - 1
And we have to ensure that debug info for bar will map to bar.1, not
to bar, at the point bar.1 is initialized.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}