public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@redhat.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: pruning unused debugging types (enums/PR23336)
Date: Thu, 17 Nov 2005 23:09:00 -0000	[thread overview]
Message-ID: <20051117230925.GB21279@redhat.com> (raw)
In-Reply-To: <20051117220835.GA8907@redhat.com>

On Thu, Nov 17, 2005 at 06:08:35PM -0400, Aldy Hernandez wrote:
> On a similar note than PR debug/21391...
> 
> In PR23336 we have the same thing happen with enums:
> 
> 	enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
> 
> 	use JTI_PROMOTED_BYTE_TYPE_NODE
> 
> JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
> use it.  I see two alternatives:
> 
> 	1. Don't prune enumeration types.
> 	2. Similar solution to PR21391: mark all enum types we use as
> 	   un-prunable in the front-end.
> 
> Thoughts?
> 
> Aldy
> 
> p.s. PING: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01227.html

I'm not altogether fond of either of these.  The problem, as I 
see it, is that we don't actually know if either the case type
or the enum type is used in any of the code that actually makes
it into the object file.

If we're going to devolve into marking everything that's ever
used once, we might as well rely on the TREE_USED bit on the type;
in the end it isn't going to make a difference, seeing as how we
will tend to pull in all of the types anyway.  Which would seem to
defeat the purpose of eliminating unused types in the first place.

If we're going to keep elimination of unused types, we're going to
have to come up with something new to associate used types with 
the code that uses them.  So that if the code is eliminated, the
used type will be as well.

If we set the granularity of this elimination to be the function,
we could add something to the function's debug data that could be
seen by the debug generator, and thus wouldn't be seen if the 
entire function is eliminated.

A solution that comes to mind is to have the front-end add dummy
TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
BLOCK.  If the TYPE_DECL node were marked DECL_ARTIFICIAL and had
no DECL_NAME, it'd be easy for us to notice that we shouldn't 
actually emit debug info for the TYPE_DECL itself, but that we
should consider its TREE_TYPE to be used.

I'm open to better schemes.  Perhaps a used-type hash table in
the struct function.


r~

  reply	other threads:[~2005-11-17 23:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17 22:08 Aldy Hernandez
2005-11-17 23:09 ` Richard Henderson [this message]
2005-11-18  6:24   ` Mark Mitchell
2005-11-18 20:09     ` Aldy Hernandez
2005-11-19  1:03       ` Mark Mitchell
2006-02-10 20:03     ` Aldy Hernandez
2006-02-14  2:11       ` Mark Mitchell
2006-02-14 11:52         ` Aldy Hernandez
2006-02-15  2:08           ` Mark Mitchell
2006-02-16 19:42             ` Aldy Hernandez
2006-02-17 23:53               ` Richard Henderson
2006-02-15 13:48           ` Diego Novillo

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=20051117230925.GB21279@redhat.com \
    --to=rth@redhat.com \
    --cc=aldyh@redhat.com \
    --cc=gcc@gcc.gnu.org \
    /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).