public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, jason merrill <jason@redhat.com>
Subject: Re: [debug-early] reuse variable DIEs and fix their context
Date: Thu, 28 Aug 2014 17:35:00 -0000	[thread overview]
Message-ID: <53FF6840.9030505@redhat.com> (raw)
In-Reply-To: <CAFiYyc0rftZkObJxo13UCwLvkhqMPNXkE11g-8tvdefQmhN2BQ@mail.gmail.com>

On 08/28/14 06:58, Richard Biener wrote:
> On Wed, Aug 27, 2014 at 4:42 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
>> This patch fixes a bunch of guality failures.  With it I get 144 guality.exp
>> failures vs. 163 for "make check-gcc RUNTESTFLAGS=guality.exp".  A lot
>> better than 100% fail rate ;-).
>>
>> Variable DIEs were not being reused.  Instead, variable DIEs even had the
>> wrong context (unilaterally the compilation unit).  The attached patch
>> reuses variable DIEs that have been outputted earlier.  It also fixes the
>> context by correcting the context on the second round.
>>
>> I have also added a bit field to the DIE structure to record if a DIE has
>> been generated early.
>>
>> Again, this is all a rough draft, but feel free to comment.
>
> I wonder if we can't not force a proper context die (ISTR dwarf2out.c
> lazily handles some contexts in some circumstances).  All parent

Hmmm, I don't see any of this lazy context setting you speak of, but...

> "trees" should be readily available and we should be able to create
> DIEs for them.

I wonder if instead of early dumping of all the DECLs, we could only 
dump the toplevel scoped DECLs, and let inheritance set the proper contexts.

We could start with calling dwarf2out_early_decl() for each function 
decl, and then for every global.  This is analogous to what we currently 
do for late dwarf2out.

see final.c for the functions:
       if (!DECL_IGNORED_P (current_function_decl))
         debug_hooks->function_decl (current_function_decl);

see c/c-decl.c for the globals:
       FOR_EACH_VEC_ELT (*all_translation_units, i, t)
	c_write_global_declarations_2 (BLOCK_VARS (DECL_INITIAL (t)));
       c_write_global_declarations_2 (BLOCK_VARS (ext_block));

The problem being that to calculate `ext_block' above, we need intimate 
knowledge of scopes and such, only available in the FE.  Is there a 
generic way of determining if a DECL is in global scope?  If, so we 
could do:

	foreach decl in fld.decls
		if (is_global_scope(decl))
			dwarf2out_decl (decl)

...and contexts will magically be set.

Is there such a way, or am I going about this the wrong way?

Aldy

  reply	other threads:[~2014-08-28 17:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27  2:43 Aldy Hernandez
2014-08-28 13:58 ` Richard Biener
2014-08-28 17:35   ` Aldy Hernandez [this message]
2014-08-28 18:01     ` Jason Merrill
2014-08-28 19:13       ` Richard Biener
2014-08-28 20:14         ` Jason Merrill
2014-08-29  9:09           ` Richard Biener
2014-09-03 17:55       ` Aldy Hernandez
2014-09-04 10:42         ` Richard Biener
2014-09-05  2:38           ` Aldy Hernandez
2014-09-05  9:00             ` Richard Biener
2014-09-09  0:01               ` Aldy Hernandez
2014-09-09  9:16                 ` Richard Biener
2014-09-12  0:51                   ` Aldy Hernandez
2014-09-12  8:13                     ` Richard Biener
2014-09-12 15:15                     ` Jason Merrill
2014-09-12 17:11                       ` Aldy Hernandez
2014-09-12 17:33                         ` Jason Merrill
2014-09-12 17:48                           ` Aldy Hernandez
2014-09-12 17:56                             ` Jason Merrill
2014-09-16 15:49                               ` Aldy Hernandez
2014-09-15  9:32                         ` Richard Biener
2014-09-15 18:46                           ` Jason Merrill
2014-12-18 19:26                       ` Aldy Hernandez
2014-12-19 11:20                         ` Richard Biener
2014-12-19 18:58                           ` Jan Hubicka
2014-12-19 19:01                             ` Jan Hubicka
2014-12-19 19:02                               ` Aldy Hernandez
2014-12-19 19:31                                 ` Jason Merrill
2014-12-19 19:50                                   ` Jan Hubicka
2014-12-20 10:09                                   ` Aldy Hernandez
2015-01-08 12:24                                     ` Richard Biener
2014-12-19 19:03                             ` Aldy Hernandez
2014-09-04 17:53         ` H.J. Lu
2014-09-04 17:54           ` Aldy Hernandez
2014-09-04 18:23             ` Richard Biener
2014-09-04 18:35               ` Aldy Hernandez
2014-09-04 18:38                 ` Christophe Lyon
2014-09-04 19:42                 ` Jan-Benedict Glaw
2015-01-08 15:20 Aldy Hernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53FF6840.9030505@redhat.com \
    --to=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).