more on duplicate decls

more on duplicate decls

[Kenneth Zadeck]

I have been trying to cleanup the location where the persistent ipa 
information is stored.

The original way that I did this was that I had a field in the var_ann 
structure that pointed to the ipa_information. 

Now that danny has reorganized the decls, the plan was to just add a 
field to the function_decl.

Danny has suggested that if I was going to add such a field, it should 
be a pointer to the cgraph_node and then store the persistent ipa 
information there.

I noticed that if I did this, there should be a lot of stuff that could 
fall away.  There would be no need to have the hash table that points 
from function_decls to cgraph nodes as well as there was no need for the 
master_clone field since the cgraph node that the decl pointed to would 
be just this good.  All of this sounds great... smaller,  faster.

This has not gone as easy as I had hoped.  Danny found the first 
stumbling block yesterday that the c  decl merging needed to be enhanced.

The second bug appears to be harder.  In c++, there really can be 
multiple function_decls with the same uid.

The kludge to handle them is documented in cp/name-lookup.c around line 
670 and one test case to generate them is in 
gcc/testsuite/g++.dg/opt/inline2.C.
There are several ways to go about fixing this:  One is to just abandon 
my fix and let others (such as the code sourcery people deal with it 
when they go to build a real symbol table.)

It seems like a better way is to build a table of merges that need to be 
done and find some place after the c++ front end is finished but before 
the cgraph gets built and do one scan of the code and replace all of the 
offending decls. 

Does such a location exist?

Is this the correct plan?

Kenny

Re: more on duplicate decls

[Mark Mitchell]

Kenneth Zadeck wrote:

> The kludge to handle them is documented in cp/name-lookup.c around line 
> 670

Ugh.

IMO, the right thing here is that there should be only one FUNCTION_DECL 
for a given function, ever, period.  Default arguments are not part of 
"the function" in C++; they are an aspect of particular declarations of 
the function.  The problem we're having is that we associate them with 
the FUNCTION_DECL, rather than with the bindings (mappings from names to 
FUNCTION_DECLs).

Unfortunately, fixing that properly is a rather large change.

> It seems like a better way is to build a table of merges that need to be 
> done and find some place after the c++ front end is finished but before 
> the cgraph gets built and do one scan of the code and replace all of the 
> offending decls.

After the C++ front end is done, it would be OK to canoanicalize all 
FUNCTION_DECLs with a single UID into one.  A stupid way of doing that 
would be to just walk the entire translation unit, and whenever you find 
a reference to a non-canonical copy of the FUNCTION_DECL, re-point it at 
the right one.

The C++ front end always operates in unit-at-a-time mode, so, yes, you 
could do this when the C++ front end is finished.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: more on duplicate decls

[Kenneth Zadeck]

Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> The kludge to handle them is documented in cp/name-lookup.c around 
>> line 670
>
> Ugh.
>
> IMO, the right thing here is that there should be only one 
> FUNCTION_DECL for a given function, ever, period.  Default arguments 
> are not part of "the function" in C++; they are an aspect of 
> particular declarations of the function.  The problem we're having is 
> that we associate them with the FUNCTION_DECL, rather than with the 
> bindings (mappings from names to FUNCTION_DECLs).
>
> Unfortunately, fixing that properly is a rather large change.
>
>> It seems like a better way is to build a table of merges that need to 
>> be done and find some place after the c++ front end is finished but 
>> before the cgraph gets built and do one scan of the code and replace 
>> all of the offending decls.
>
> After the C++ front end is done, it would be OK to canoanicalize all 
> FUNCTION_DECLs with a single UID into one.  A stupid way of doing that 
> would be to just walk the entire translation unit, and whenever you 
> find a reference to a non-canonical copy of the FUNCTION_DECL, 
> re-point it at the right one.
>
> The C++ front end always operates in unit-at-a-time mode, so, yes, you 
> could do this when the C++ front end is finished.
Are you saying that if I wait til the front end is finished that I do 
not have to worry about the default args problem you mention above?

Should I fix it this simple way or should I let a c++ front end person 
fix it as the decls are created?

kenny

Re: more on duplicate decls

[Giovanni Bajo]

Kenneth Zadeck <zadeck@naturalbridge.com> wrote:

> Are you saying that if I wait til the front end is finished that I do
> not have to worry about the default args problem you mention above?

Yes. The middle-end does not know anything about default arguments: they are
used only internally by the C++ frontend. When the trees enter the
middle-end, the FUNCTION_DECLs do not need the default arguments, the
CALL_EXPR are filled correctly, and the programmer errors have been already
reported.

> Should I fix it this simple way or should I let a c++ front end person
> fix it as the decls are created?


I believe the simple way is faster for you to continue with you work. The
proper fix does not look easy at all.
-- 
Giovanni Bajo