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: [debug-early] emit locals early patchset


On Tue, Oct 28, 2014 at 1:00 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> Gentlemen!
>
> My apologies for the big patch.  In getting locals emitted early (parameters
> and locally scoped variables), I ran into many things which were in need of
> surgery, many of which couldn't happen without the other.  Consequently, I
> ended up fixing everything such that we are now back to no guality.exp
> failures for any language.
>
> [Curiously, I hadn't noticed locals were not being dumped early because they
> were being picked up by the late dwarf pass.  Fixing this oversight is what
> caused this entire patch.]
>
> There are a lot of changes here, and I would greatly appreciate feedback, so
> let me at least explain what's going on at a high level...
>
> 1. Changes to gen_subprogram_die() to handle early generation of locals, and
> amending location information on the second pass.  Everything else in this
> patch, basically stems from this change.
>
> 2. Changes to gen_variable_die() to handle multiple passes (early/late dwarf
> generation).
>
> A lot of this is complicated by the fact that old_die's are cached and keyed
> by `tree', but an abstract instance and an inline instance share trees,
> while dwarf2out_abstract_function() sets DECL_ABSTRACT_P behind the scenes.
>
> The current support (and my changes) maintain this shared and delicate
> design.  I wonder whether we could simplify a lot of this code by unsharing
> these trees, but this may be beyond the scope of this work. Richi perhaps
> you can comment?

I think that the abstract and inline instances are cases that are _only_
generated "early" - that is, they don't contain any locations or whatever
and thus do not need to ameded in the late dwarf pass.  So I'd simply
generate dwarf for them and not remember their DIEs.

But maybe I am missing something here ;)

They are also only a space optimization I think - the trees are there
in the inline instances and we can fully re-generate them from there.

Richard.

> 3. I've removed deferred_locations.  With multiple dwarf passes we can do
> without them.
>
> 4. I have commented a lot of dwarf2out.c throughout .  Dwarf generation is
> this big mystery, and my brain is small.  I've commented things as I've
> learned them.  Hopefully it can help those unfortunate souls who come after
> me.
>
> 5. Variable-lengthed array types need special treatment.  Even though they
> can be early dumped, location information may not be available until late
> dwarf.  I've modified gen_type_die*() and friends to work with
> variable-lengthed arrays.  Now we will early generate the
> DW_TAG_subrange_type, but fill in the location at late dwarf.
>
> 6. Handle dual passes through gen_lexical_block_die(), while handling
> inlining gracefully.
>
> Here I use a new tree bit (BLOCK_DIE) to store the DIE<->block relationship.
> This will have to be adapted and streamed for LTO.
>
> For that matter, LTO as a whole needs addressing, but I want to get the
> non-LTO version working before I dive into dwarf streaming, and removing all
> these ancillary data structures in dwarf2out.  Right now, LTO is working but
> only because everything gets recreated by the late dwarf pass, thus it's
> working as in mainline.
>
> Phew... that's basically it.
>
> Kind words greatly appreciated.  Basically I'm looking for feedback and
> positive reinforcement that this is all eventually useful :).
>
> Aldy
>
> p.s. Committed to branch.


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