[cfe-dev] PATCH: Cleanup function redeclaration representations

Chris Lattner clattner at apple.com
Sun May 4 11:19:33 PDT 2008

On May 4, 2008, at 1:42 AM, Argiris Kirtzidis wrote:
> Hi Chris,
> I really like the idea of keeping the decls clean and having a  
> separate 'aggregate' decl. I have two suggestions for consideration:
> --The 'isaggregate' bool is not needed if we assume that, when we  
> walk the list of redecls, the last one is the 'aggregate' one.

Makes sense to me.  Alternatively...

> --Another suggestion is to not add to the scope chain the  
> redeclarations (at all 5 cases, Scope[foo] = 1), thus all calls to  
> 'foo' will refer to the same FunctionDecl node.
> One way to go about this would be to have a double linked list of  
> redeclarations, and the (V) case would be:
> A: foo [prevdecl=null, nextdecl=null]  void foo(int x = 12, int y =  
> 0);  // does the 'aggregate' need to point to #1 as nextdecl ?
> 1: foo [prevdecl=A, nextdecl=2]  void foo(int x, int y);  // this is  
> what all calls to 'foo' refer to
> 2: foo [prevdecl=1, nextdecl=3] void foo(int x, int y);
> 3: foo [prevdecl=2, nextdecl=4] void foo(int x, int y = 0);
> 4: foo [prevdecl=3, nextdecl=null] void foo(int x = 12, int y);
> following prevdecl, last one = #A = aggregate
> We could use two DenseMaps to store the redeclaration links, similar  
> to the way Doug is using one in his patch, thus not bloating  
> ScopeDecls.
> (just to be pedantic again, on the above case, if #A doesn't link to  
> #1 as nextdecl, we save a link :) )

How about just storing the list in reverse order.  This means that  
adding a new redecl would have to walk the list (to add the redecl to  
the end of the singly linked list), but that the aggregate version  
would always be at the head of the list.  This would make redecls  
slower but would make references to the function constant time.  Given  
that there are usually not hundreds of redecls of functions, I think  
it would be ok.  If we find that walking the list *is* a problem,  
there are more complex/clever solutions possible too.


More information about the cfe-dev mailing list