VTA merge - ssa (gimple, trees, tuples)

[Richard Guenther]

On Fri, Jun 5, 2009 at 9:13 PM, Alexandre Oliva<aoliva@redhat.com> wrote:
> On Jun  5, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:
>
>>  - IS_DEBUG_STMT should be a gimple_debug_p or is_gimple_debug
>>    inline function in gimple.h.  In fact, all of the macros that operate on
>>    gimple should be inline functions and in gimple.h.  They also need
>>    documentation in gimple.texi (maybe that follows, I'm not that far yet).
>
> Aaah, the wonders of old patches being maintained over so many moons
> with multUple changes ;-)
>
> Thanks, will fix.  Likewise IS_DEBUG_BIND.
>
>>  - all the adjustment needed for keeping definitions of debug-uses
>>    dominating the debug-stmts after code motion have probelems
>>    * they require up-to-date dominators
>>    * they look just ugly
>>    why not allow non-dominating definitions for debug-stmts (thus,
>>    adjust the verifier) and have a cleanup pass (like we have
>>    TODO_remove_unused_locals or cfgcleanup) to rip them out?
>>    That would reduce the complexity of the fixup as well.
>
> Summing up the explanation on IRC:
>
> We do have the lazy cleanup, it's implemented in
> check_and_update_debug_stmt()
>
> The few cases in which this doesn't work are when we remove a DEF, as in
> release_ssa_name() (we have to remove all debug USEs right away, lest
> the node gets reused and we get thoroughly confused or even crash), or
> when we move a DEF past debug USEs of it.
>
> In both cases, if lazy update even worked, it would have just dropped
> the info.  These explicit updates enable us to retain the info,
> propagating the DEF rhs into the debug uses that are affected by the
> move or remove.
>
>>  - I don't see the point of var_debug_value_for_decl, or rather its
>>    complicatedness.  We should always have a DECL_NAME for
>>    !DECL_ARTIFICIAL.
>
> Clearly at some point we didn't, maybe we still don't.  Are you sure
> that is so for Java DECLs?
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00759.html

I guess those are DECLs for artificial temporaries created by compiling
to bytecode.  The fix is to set DECL_ARTIFICIAL on them.

>> Why look up abstract origins?
>
> Perhaps because that's how Java VM slots get related to source variables
> that were present in the .java sources?  Honestly I don't remember, but
> hopefully these questions will be enough to explain why I did this.

Maybe, but it still doesn't look right.  Fixing the Java frontend is IMHO
better.

>> Why test MAY_HAVE_DEBUG_STMTS so late?
>
> Mainly because the other tests seemed cheaper: more likelihood to get a
> cache hit.  I can move it up if you feel it would make it better.  I
> haven't made any actual measurements.
>
>> Why does MAY_HAVE_DEBUG_STMTS exist at all - you should just test
>> flag_var_tracking
>
> At some point it tested more than just that one flag.  It also tested
> for optimization and debug info generation selection.  So you can see
> now how I got the idea it might be more expensive to test it first ;-)
>
>> (or as I suggested elsewhere enable debug stmts unconditionally in the
>> end).
>
> This very possibility is one argument to keep abstracting the test into
> a macro, for then, if we change flag_var_tracking to indicate whether to
> emit debug statements and also whether to use them or discard them in
> the var-tracking pass, the test might have to change.

Well, ok.

Thanks,
Richard.