Re: PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun 28, 2007, ""Seongbae Park (ëìë, ææå)"" <seongbae.park@gmail.com> wrote:

> Can you show me one example of the code
> where this patch helps, and why it helps the runtime performance ?
> e.g. gap

I couldn't find any situation in which this patch by itself preserved
more variables in a useful way.  It's not a complete solution for the
problem of destroying debug information; far from it.

Two examples of variables that it preserves in gap are in aggroup.c:
ModAg's hdL and PowAgAG's hdR are used to hold return values, and
they're preserved in the inlined copies in TModAg and TPowAgAg.
Unfortunately, the values held in them are not really meaningful for
the user, since no changes to these variables are expected.  Yet
another debug-info bug.

As for the performance improvement, I can't quite explain what caused
the differences.  Only half a dozen of the gap sources had any
differences whatsoever in object files, and by inspecting the
generated assembly for them I found the following differences:

agcollec: irrelevant, pretty much only scheduling

aggroup: TModAg and TPowAgAg get smaller stack frames in spite of the
additional variable

eval: CopyForward and CopyCleanup, a bunch of stores of the return
value of NrHandles (inlined recursions) are moved past the loop entry
test

function: mostly irrelevant, pretty much only scheduling, a tiny little
bit of extra copying, a few differences in basic block ordering

read: mostly irrelevant, pretty much only scheduling, a tiny little
bit of extra copying, a few differences in basic block ordering

unknown: irrelevant, pretty much only scheduling, a tiny little bit of
extra copying

word: irrelevant, pretty much only scheduling

> This is not to say I object to your patch - rather I'm flabbergasted
> than anything that disabling coalescing at gimple has such a low
> impact -

Yes, there are numerous other passes that end up discarding inlined
variables, including function inlining itself.

My current plan to address this is to arrange for assignments to user
variables that we'd currently remove to be instead modified into debug
assignments, i.e., assignments that we don't generate code for (only
debug notes), whose outputs are never used as inputs in any non-debug
assignments, and whose inputs can become arbitrarily complex
expressions.

I'm still not sure how to implement this, or whether keeping such
assignments around might still harm optimizations somehow, but this is
what I've managed to come up with.

When such assignments are introduced, we can disable the coalescing of
all user variables, and instead emit this kind of debug assignment for
them out of the coalesced variable.


Another alternative that looks simpler to me is generate temps for all
user variables upfront, such that assignments to user variables are
*always* debug-only statements:

  Tfoo = Tbar;
  # foo = Tfoo;

Then, if the optimizer ever decides to optimize Tfoo away, it must
have already modified the debug assignment to the foo user variable:

  Tfoo = Tbar; // Tfoo is dead, it can be thrown away
  # foo = Tbar;

Any ideas of how to represent such debug assignments?  I'm undecided
as to whether to use some flag in gimple_modify_stmt, wrap the output
variable somehow, or use a different tree code.  Also, I'm not sure
whether or not this kind of debug assignment should be handled in any
way by the SSA machinery (I don't think so).  It should definitely
allow non-gimple input expressions very early in the game, to try to
make sure variables are never kept around just because some debug
variable needs that value.

Does this make any sense?  Any other suggestions, thoughts, things to
watch out for, anything?

Thanks,

-- 
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}