the size of tree_decl

the size of tree_decl

[Dan Nicolaescu]

tree_decl is a big structure (108 bytes on x86), a lot of tree_decls are
created during a compilation and a lot more are created on the
tree-ssa branch. 

It seems that there are some things in a tree_decl that could be
placed somewhere else, and save some space that way. 


  tree vindex;  -- seems to be only used in C++ and java
Can it be moved to the language specific part of the decl?


  /* In a FUNCTION_DECL, this is DECL_SAVED_TREE.  */
  tree saved_tree;
  /* In a FUNCTION_DECL, these are function data which is to be kept
     as long as FUNCTION_DECL is kept.  */
  tree inlined_fns;

These seem to be only used for FUNCTION_DECLs. Can they be added as
an attribute to FUNCTION_DECLs instead of taking up space for all the
decl types? 

Also not all decl types use these:

  tree assembler_name;
  tree section_name;
  rtx rtl;	/* RTL representation for object.  */

None of these fields are accessed very often, so it shouldn't be a
big problem that they are stored somewhere else. 

Comments? 

[unfortunately I won't have time to work on this for about a month, so
if somebody wants to implement this in the meanwhile, please do so]

Re: the size of tree_decl

[law]

In message <200302102217.h1AMHvkA027073@gremlin.ics.uci.edu>, Dan Nicolaescu wr
ites:
 >
 >tree_decl is a big structure (108 bytes on x86), a lot of tree_decls are
 >created during a compilation and a lot more are created on the
 >tree-ssa branch. 
 >
 >It seems that there are some things in a tree_decl that could be
 >placed somewhere else, and save some space that way. 
I'm all for it :-)

 >  tree vindex;  -- seems to be only used in C++ and java
 >Can it be moved to the language specific part of the decl?
Hmm, I'm somewhat surprised it's not used by Obj-C.  No strong
opinions here.

 >  /* In a FUNCTION_DECL, this is DECL_SAVED_TREE.  */
 >  tree saved_tree;
 >  /* In a FUNCTION_DECL, these are function data which is to be kept
 >     as long as FUNCTION_DECL is kept.  */
 >  tree inlined_fns;
 >
 >These seem to be only used for FUNCTION_DECLs. Can they be added as
 >an attribute to FUNCTION_DECLs instead of taking up space for all the
 >decl types? 
That would be wise.

 >
 >Also not all decl types use these:
 >
 >  tree assembler_name;
 >  tree section_name;
 >  rtx rtl;	/* RTL representation for object.  */
 >
 >None of these fields are accessed very often, so it shouldn't be a
 >big problem that they are stored somewhere else. 
I'm not real keen on moving data out just to store it somewhere 
else -- unless the data is only used on a few specific nodes

Jeffk

Re: the size of tree_decl

[Dan Nicolaescu]

law@redhat.com writes:

  > In message <200302102217.h1AMHvkA027073@gremlin.ics.uci.edu>, Dan Nicolaescu wr
  > ites:
  >  >
  >  >tree_decl is a big structure (108 bytes on x86), a lot of tree_decls are
  >  >created during a compilation and a lot more are created on the
  >  >tree-ssa branch. 
  >  >
  >  >It seems that there are some things in a tree_decl that could be
  >  >placed somewhere else, and save some space that way. 
  > I'm all for it :-)

Great!

  > 
  >  >  tree vindex;  -- seems to be only used in C++ and java
  >  >Can it be moved to the language specific part of the decl?
  > Hmm, I'm somewhat surprised it's not used by Obj-C.  No strong
  > opinions here.

I am not too sure, I just grepped for vindex, and there were no hits
in the objc directory...

There's another field that is too big: location_t locus, it contains
a line number and a char*. If it was to use logical lines like cpplib
does, the char* 

Some numbers to show why keeping tree_decl small is important. 
cc1 -O2 combine.i 

Memory allocated for decls: 987336 bytes
Total ggc alocated memory 5372k

ie 18% of the ggc memory is allocated for tree_decls

for C++: 

cc1plus -O2 generate-3.4.ii  (from Gerald Pfeifer's PR 8361, I have no
                              idead how typical that code is)

Memory allocated for decls: 15630408 bytes
Total ggc alocated memory: 48M

ie 31% of the ggc memory is allocated for tree_decls


        --dan

Re: the size of tree_decl

[Neil Booth]

Dan Nicolaescu wrote:-

> There's another field that is too big: location_t locus, it contains
> a line number and a char*. If it was to use logical lines like cpplib
> does, the char* 

That's the ultimate plan.  Try doing for the whole compiler though.
What a nightmare.

Per was working on adding column info and still using just 32 bits.
Sounded a bit tight to me.  That's gone quiet.

Neil.

Re: the size of tree_decl

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

| Dan Nicolaescu wrote:-
| 
| > There's another field that is too big: location_t locus, it contains
| > a line number and a char*. If it was to use logical lines like cpplib
| > does, the char* 
| 
| That's the ultimate plan.  Try doing for the whole compiler though.

Yep.  Don't forget that RTL also has an equivalent of location_t -- an
int and char*.  If you're going to save memory for location_t, please
first try to replace the RTL equivalent with location_t, then optimize
loccation_t into a cpplib-like data type.

-- Gaby

Re: the size of tree_decl

[law]

In message <20030212224744.GB14744@daikokuya.co.uk>, Neil Booth writes:
 >Dan Nicolaescu wrote:-
 >
 >> There's another field that is too big: location_t locus, it contains
 >> a line number and a char*. If it was to use logical lines like cpplib
 >> does, the char* 
 >
 >That's the ultimate plan.  Try doing for the whole compiler though.
 >What a nightmare.
 >
 >Per was working on adding column info and still using just 32 bits.
 >Sounded a bit tight to me.  That's gone quiet.
What we do on the tree-ssa branch (where the locus is common to all nodes)
is have a pointer to external locus data, which can be shared across
nodes.

I wouldn't recommend this for the mainline tree though.  tree-ssa has
an interesting requirement that location information be tied to exprs,
decls and other nodes.  The alternative was to create expression nodes
to carry locus information around.  After doing the algebra it was
pretty clear that we were better off with the locus pointer in tree_common
plus sharing rather than having lots of wrapper nodes carrying line
information.

jeff

Re: the size of tree_decl

[Per Bothner]

Neil Booth wrote:
> Per was working on adding column info and still using just 32 bits.
> Sounded a bit tight to me.  That's gone quiet.

I'm currently working on turning cc1/cc1plus/... into a
"compile server".  I have a proof-of-concept C-only prototype
and a design document I hope to post next week.  In
conjunction with that work, it may make sense to also do
something about line numbers, but I haven't so far.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: the size of tree_decl

[law]

In message <200302122025.h1CKPDkA024739@gremlin.ics.uci.edu>, Dan Nicolaescu 
writes:
 >  >  >  tree vindex;  -- seems to be only used in C++ and java
 >  >  >Can it be moved to the language specific part of the decl?
 >  > Hmm, I'm somewhat surprised it's not used by Obj-C.  No strong
 >  > opinions here.
 >
 >I am not too sure, I just grepped for vindex, and there were no hits
 >in the objc directory...
Again, I'm just surpried.  I thought Objective-C had virtual function
calls.  It's possible they're implemented without using vindex.

 >There's another field that is too big: location_t locus, it contains
 >a line number and a char*. If it was to use logical lines like cpplib
 >does, the char* 
Yup.  locus information can be a significant hog. 



 >Some numbers to show why keeping tree_decl small is important. 
 >cc1 -O2 combine.i 
No surprise there.  We *know* decls are a huge amount of the memory
consumed by the compiler.  In the back of my mind I keep thinking
that we should be able to make more sense of the zillions of fields
in DECL nodes and possibly break out some things that don't make
sense.  I also get the sense that we over-use decl nodes for things
that really aren't decls -- if I remember correctly all the "statement"
nodes in the C front-end are implemented as DECLs.  Ugh.

Jeff

Re: the size of tree_decl

[Pop Sébastian]

On Fri, Feb 14, 2003 at 12:52:23PM -0700, law@redhat.com wrote:
> that really aren't decls -- if I remember correctly all the "statement"
> nodes in the C front-end are implemented as DECLs.  Ugh.
> 

DEFTREECODE (SWITCH_STMT, "switch_stmt", 'e', 3)

All *_STMT nodes are declared as 'e' (= expressions).

Re: the size of tree_decl

[law]

In message <20030214204620.GA26259@gauvain.u-strasbg.fr>, =?iso-8859-1?Q?Pop_S=
E9bastian?= writes:
 >On Fri, Feb 14, 2003 at 12:52:23PM -0700, law@redhat.com wrote:
 >> that really aren't decls -- if I remember correctly all the "statement"
 >> nodes in the C front-end are implemented as DECLs.  Ugh.
 >> 
 >
 >DEFTREECODE (SWITCH_STMT, "switch_stmt", 'e', 3)
 >
 >All *_STMT nodes are declared as 'e' (= expressions).
You are correct.  My bad.  The _STMT nodes are 'e' expressions and their
line number is stored in the complexity field of an expr.  For DECL nodes
their locus is stored in the locus field within decl nodes.

My how quickly my memory fades.

jeff

Re: the size of tree_decl

[Richard Henderson]

On Fri, Feb 14, 2003 at 12:52:23PM -0700, law@redhat.com wrote:
> Again, I'm just surpried.  I thought Objective-C had virtual function
> calls.  It's possible they're implemented without using vindex.

Yep.  Such calls go into the objc runtime for the lookup, at which point
they start using __builtin_apply (a continual source of problems) and such
to bounce to the target function.


r~