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~
