This is the mail archive of the 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 Fri, Jun 5, 2009 at 9:13 PM, Alexandre Oliva<> wrote:
> On Jun ?5, 2009, Richard Guenther <> 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
> Clearly at some point we didn't, maybe we still don't. ?Are you sure
> that is so for Java DECLs?

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

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


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