Re: pruning unused debugging types (enums/PR23336)

[Aldy Hernandez <aldyh@redhat.com>]

Hi folks.

Sorry I've taken so long on this.  There was this marriage thing in
which I was a protagonist, and it's gotten me way off balance :).

I've been chasing my tail on implementation details.  I was hoping
someone could give me a few hints.

 >> 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.

 > I like the idea, but I think a hash table would be better.  In fact, I
 > think the best choice would be a hash table during compilation of the
 > function, transformed into a vector after the closing brace of the
 > function, so that we do not have the wasted memory associated with
 > either dummy TYPE_DECLs or hash table entries.  Also, we should do this
 > only for the kinds of types we tend to lose (maybe casts and enums?), to
 > keep the extra memory cost to a minimum.

So far the way I've envisioned (correct me if I'm wrong please), is to
add 2 entries to struct function: one for a hash table which will be
freed when we're done parsing the function, and one containing the
vector of used types.

I'd like to avoid adding 2 entries, but just the vector.  However,
parsing nested functions require us to keep a used type hash table for
each function while we parse.  Mark is this ok (adding 2 entries)?

[I was thinking we could have a static stack of hashes of used types
in the parser, and only pollute struct function with the vector.  Mark
what did you have in mind?]

[Diego suggested doing all this in the gimplifier, since we gimplify
one function at a time plus we'd only have to implement this once
instead of in each parser, but by the time the gimplifier gets a hold
of things like "(struct foo *)0x1234)->I", we no longer have a cast;
it has been decomposed into an INDIRECT_REF.]

Problem number two... I'm apparently GTY clueless, and have been
unable to declare a vector of trees as a field of struct function.
So far I have:

        VEC(tree,gc) * GTY (()) used_types_vector;

This gives me:

        build/gengtype /blah/function.h:324: unidentified type
        `VEC_tree_gc'

I've also tried:

        GTY (()) VEC(tree,gc) *used_types_vector;

        build/gengtype /blah/function.h:324: syntax error, unexpected GTY_TOKEN, expecting '}'

I've been looking for examples of tree VECTORs in GTY'able structures
to no avail, and my GTYfoo is as good as my surfing (I know I'm
supposed to go on the surfboard, but that's about it).

Below is my non working patch to function.h.

Any ideas?  Thanks.
Aldy

Index: function.h
===================================================================
--- function.h  (revision 110692)
+++ function.h  (working copy)
@@ -23,6 +23,11 @@ Software Foundation, 51 Franklin Street,
 #define GCC_FUNCTION_H

 #include "tree.h"
+#include "hashtab.h"
+#include "ggc.h"
+#include "alloc-pool.h"
+#include "varray.h"
+#include "vec.h"

 struct var_refs_queue GTY(())
 {
@@ -312,6 +317,12 @@ struct function GTY(())
   /* Language-specific code can use this to store whatever it likes.  */
   struct language_function * language;

+  /* Used types hash table.  */
+  htab_t GTY ((param_is (union tree_node))) used_types_hash;
+
+  /* Used types vector.  */
+  GTY (()) VEC(tree,gc) *used_types_vector;
+
   /* For reorg.  */