On Wed, Feb 25, 2015 at 11:54:16AM +0100, Richard Biener wrote:
> > Regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to install?
>
> But code-motion could still move stmts from the inlined functions
> across these resets? That said - shouldn't this simply performed
> by proper var-tracking u-ops produced by a backward scan over the
> function for "live" scope-blocks? That is, when you see a scope
> block becoming live from exit then add u-ops resetting all
> vars from that scope block?
Yeah, wanted to say the same, I'm afraid such a change will very much affect
debugging experience close to the end of inlined functions, as sinking,
scheduling and various other passes may move statements from the inline
functions across those resets. And, various tools and users really want to
be able to inspect variables and parameters on the return statement.
So, IMHO to do something like this, we'd need to mark those debug stmts
some way to say that they aren't normal debug binds, but debug binds at the
end of scopes (whether inlined functions or just lexical blocks), and
optimization passes that perform code motion should try to detect the case
when they are moving downward some statements across such debug stmts and
move those debug stmts along with those if possible.
And another thing is the amount of the added debug stmts, right now we don't
add debug stmts all the time for everything, just when something is needed,
while your patch adds it unconditionally, even when debug stmts for those
won't be really emitted. As they are just resets, that hopefully will not
drastically affect var-tracking time, but might affect other optimization
passes, which would need to deal with much more statements than before.
Jakub
