PR 23551: why should we coalesce inlined variables?

Andrew MacLeod amacleod@redhat.com
Thu May 10 14:30:00 GMT 2007


On Thu, 2007-05-10 at 04:39 -0300, Alexandre Oliva wrote:
> We're discarding useful debug info by SSA-coalescing inlined
> variables.  The reason we refrain from coalescing non-inlined
> variables is for better debug info.  No other pass pays attention to
> DECL_FROM_INLINE, and it doesn't look like we generate significantly
> worse code if we refrain from coalescing these variables.  So...
> 
> May I check this in if it passes bootstrap and regression testing on
> x86_64-linux-gnu?


Not without some real performance measurement.  We originally added this
specifically to remove a number of excess copies that heavy inlining
produces.

Out of ssa will not coalesce anything which doesn't have the same base
variable, and often we end up with a lot of copies generated by inlining
which only exist because their names didn't match what they are copied
into.

copyrename doesn't *actually* coalesce two variables. It merely changes
the name of a variable so that it might get coalesced later if it is
worthwhile.  That is why we don't do direct user variables themselves.
You can easily get 3 or 4 different user variables which end up all with
the same name, and are often not coalesced. On the other hand, inline
variables often are coalesced.

How often 2 inline variables are coalesced to each other I'm not sure,
hence that is why Id want to see actual performance measurements.  I've
actually considered the opposite and removing the restriction on user
variables at -O3, and just let everything coalesce. I think we had a PR
(or part of a PR) once upon a time that would have been resolved by
doing that. It definitely makes a mess of debug info when you do that
however. 

It might also be possible to 'save' the original name in a table, and if
a useful coalesce was not performed at out of ssa time, rename the
variable back, or choose the most 'useriest' name amongst a coalesce
group... That might also help debug info a bit.

Andrew



More information about the Gcc-patches mailing list