This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VTA merge - ssa (gimple, trees, tuples)


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


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

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

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]