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 Wed, Nov 5, 2014 at 5:06 PM, Martin Jambor <mjambor@suse.cz> wrote:
> On Tue, Oct 28, 2014 at 03:57:43PM +0100, Richard Biener wrote:
>> 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.
>
> Please have a look at PR 63722, which is a complaint I got from people
> exploring possiblities of using dwarf to analyze what gcc did to Linux
> kernel and they discovered that DIEs of  abstract origins do not have
> their DW_AT_inline set correctly for functions that were IPA-SRAed but
> not inlined.  On the original testcase before reduction I've seen the
> same problem also when using -fno-ipa-sra -fno-ipa-cp so it is not
> just my passes but also probably ipa-split ;-)
>
> In any case, if we want abstract origins to have this field set
> correctly in abstract origins, we need to have the possibility to
> modify it after IPA.

My point is we don't need the abstract origins at all - they are a DWARF
bytecode space optimization.

Richard.

> Martin


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