[cfe-dev] PATCH: Cleanup function redeclaration representations

[Argiris Kirtzidis]

Chris Lattner wrote:
>
> On May 4, 2008, at 2:37 PM, Argiris Kirtzidis wrote:
>
>> Chris Lattner wrote:
>>>> --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.
>>
>> The issue with the reverse order single list is that when the 
>> consumer receives a redecl it cannot know if it's a redecl (the last 
>> decl doesn't point to another decl), and even if we add a flag to 
>> indicate it, the consumer will know that it's a redecl but it will 
>> not be able to get the original decl and/or the aggregate one from 
>> the latest redecl.
>
> Do you mean that you can't tell if you are looking at the aggregate 
> decl or a real decl?  If so, the aggregate decl could just have a null 
> source location, to indicate that it is synthetic.

Following your example, at first there is:

void foo(int x, int y);  // #1
1: foo [nextredecl=null]    void foo(int x, int y);

the consumer receives #1 (through HandleTopLevelDecl() )

Then:

void foo(int x, int y=2);  // #2

A: foo [nextredecl=1]    void foo(int x, int y=2);
1: foo [nextredecl=2]    void foo(int x, int y);
2: foo [nextredecl=null]   void foo(int x, int y=2);

The consumer receives #2 :
2: foo [nextredecl=null]   void foo(int x, int y=2);

How can it find out whether #2 is a redecl and that #A is the aggregate ?


-Argiris