Re: [RFC] Add DECL_CHAIN and some other *_CHAIN

[Mike Stump <mrs at apple dot com>]

On Dec 26, 2005, at 10:22 PM, Andrew Pinski wrote:
> What do people think about this patch, it is very mechanical.

A couple of thoughts, first, timings for C++ (once converted) at -O0  
as chain influences time more than most, and I suspect we'd want all  
languages bootstrapped and tested before any mid end backend code  
goes in, just to be sure a front end isn't misusing any part of the  
tree and it sure would be nice if the complier had hard types for  
those places that used something like DECL_CHAIN to ensure it was a  
decl, but, failing that, I'd hope that you could ensure that the  
documentation reflects the new assert.  For example, take  
DECL_ARGUMENTS:

  tree arguments;       /* Also used for DECL_FIELD_OFFSET */

/* In FUNCTION_DECL, a chain of ..._DECL nodes.
   VAR_DECL and PARM_DECL reserve the arguments slot for language- 
specific
   uses.  */
#define DECL_ARGUMENTS(NODE) (DECL_CHECK (NODE)->decl.arguments)

here, we don't have hard typing, but, we do have documentation which,  
if people followed and if complete would make the conversion of this  
one reasonably safe (ignoring non-C fonrtends).

Once you convert C++, you'd find:

/* The DECL_TEMPLATE_PARMS are a list.  The TREE_PURPOSE of each node
   is a INT_CST whose TREE_INT_CST_LOW indicates the level of the
   template parameters, with 1 being the outermost set of template
   parameters.  The TREE_VALUE is a vector, whose elements are the
   template parameters at each level.  Each element in the vector is a
   TREE_LIST, whose TREE_VALUE is a PARM_DECL (if the parameter is a
   non-type parameter), or a TYPE_DECL (if the parameter is a type
   parameter).  The TREE_PURPOSE is the default value, if any.  The
   TEMPLATE_PARM_INDEX for the parameter is available as the
   DECL_INITIAL (for a PARM_DECL) or as the TREE_TYPE (for a
   TYPE_DECL).  */
#define DECL_TEMPLATE_PARMS(NODE)       DECL_ARGUMENTS (NODE)

which, well, I think might run afoul of and backend/midend changes at  
first.

> Should I submit this patch in different parts as this patch/ 
> changelog is huge?

Didn't seem that huge to me.