This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc at gcc dot gnu dot org, dan at debian dot org, rguenther at suse dot de, martinj at suse dot cz
- Date: Fri, 06 Mar 2009 15:53:38 -0300
- Subject: Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)
- References: <20090305105431.GD32299@kam.mff.cuni.cz>
On Mar 5, 2009, Jan Hubicka <firstname.lastname@example.org> wrote:
> The patch adds mechanizm for tracking inline substitutions, so we
> actually note that on whole scope of its existence ARGUMENT is having
> same value as OTHERARGUMENT.
> So if we want to have DEBUG_INSN approach, those aproaches should
> combine themselves well: inline substitution tracking will handle most
> cases chaply and DEBUG_INSN will help to keep the substitutions valid.
I concur. I don't see any incompatibility whatsoever. It's a perfect
fit, and a great improvement.
> I make attempt in tree-inline to look up stable enough replacement in
> simplify_replacement (i.e. walking SSA graph and trying to find something
> that is not going to disappear, as function parameter, user variable
> or address of user variable) and I am not making any attempts to update
> replacement removing them when variables they refer to become dead
> though I think we can do some job here.
VTA could help here, I suppose, if the value of the dead variable
remains available somewhere. Gotta think a bit about this, but I don't
see that this would be too difficult.
> Finally when it comes to dwarf encoding the main problem seems to be that
> dwarf insist on describing function value as location in memory. This is
> not quite compatible with values passed by reference where we optimize out
> the pointer to value and thus we still know address it points to but we no
> longer have memory location for the pointer itself.
I feel your pain ;-)
> There is DW_OP_value in dwarf4 for that but it is not supported by
Long term, this is certainly what we should use.
> Important fact is also that tracking is very cheap.
> So I wonder if there are some comments?
Three words: way to go! :-)
> Since dwarf allows to express memory location consisting
> of multiple places, it should be possible to fully track simple SRAed out
> we are however lost when we have pointer to those struct since there
> is no means describing "there is no memory location for this pointer,
> but it would be pointing to this structure" except for my
> aforementioned hack of unpeeling references/pointers.
Uhh... I get the impression that, if the struct could be fully SRAed,
that's because any pointers to it were determined to be totally dead, in
which case not having debug info for it is perfectly legitimate
(complete and correct, as per the VTA criteria).
Or are you speaking of cases in which the struct is only temporarily
SRAed, with the pieces put back in place whenever a pointer that could
point to it is dereferenced? This case would be tricky to handle,
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
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