[VTA] retain more debug info in loop-ivopts

[Richard Guenther]

On Sat, Sep 5, 2009 at 3:03 AM, Alexandre Oliva<aoliva@redhat.com> wrote:
> On Sep  4, 2009, Alexandre Oliva <aoliva@redhat.com> wrote:
>
>>> A more convincing option would be to not delete the stmts in IVOPTs
>>> but instead rely on a later DCE.  Does that work and generate equivalent
>>> code?
>
>> I'll give it a try.
>
> It's much slower than the patch I proposed, and it misses optimization
> opportunities because of the lingering useless stmts.
>
> While my patch causes no visible compile-time variation (+/- 1% faster
> or slower), your suggestion made varied from 0.5% faster to 3% slower,
> on libiberty/regex.c.
>
> It's not hard to imagine why.  Basically it means dropping useful
> information about which stmts can be deleted, and carry them around
> longer until we find out again that they're useless.
>
>> Here's how I'm going to test it: write a scratch
>> patch that introduces option to disable the call to remove_unused_ivs,
>> and then run a stage3 build with GCC_COMPARE_DEBUG=-fthat-option.
>
> This test didn't work: there were too many differences in internal
> representation that turned out not to be significant.  However, even
> using different stages for a compare (STAGE2_CFLAGS and STAGE3_CFLAGS)
> failed on more than a dozen object files.

Too bad.

What I am concerned with is that over time we'll aggregate this kind of
hacks all over the optimization passes that happen to remove statements
at some point.

Thus, can you at least change the patch so it stores SSA name versions in
the bitmap and move the topological walk and stmt remove to a helper
function (also getting rid of the weird remove_statement helper) in
tree-ssa.c (well, where you put the other debug stmt related helpers)?

+           /* We can't propagate PHI nodes into debug stmts.  */
+           if (gimple_code (stmt) == GIMPLE_PHI

that would mean we can remove PHI nodes immediately, no?  Thus we
can skip walking immediate uses for SSA names whose definitions are
PHIs?

What is odd about remove_statement is the get_phi_with_result function.
It's obviously a no-op, the defining statement of the phi result is the phi
itself (it's so weird that I must miss something).  Can you kill that while
you are around that corner?

Thanks,
Richard.