Lazy allocation of DECL_ASSEMBLER_NAME

[Dale Johannesen]

On Mar 1, 2004, at 12:21 PM, Geoff Keating wrote:

>> From: Zack Weinberg <zack@codesourcery.com>
>> Date: Mon, 01 Mar 2004 11:57:56 -0800
>
>> Geoff Keating <geoffk@geoffk.org> writes:
>>
>>> Likewise, I believe with Zack's c-decl changes, I believe that it
>>> always returns the new DECL,
>>
>> I can't speak to anything else here, but this is not true; I
>> considered that approach and rejected it.  The thrust of the
>> (currently incomplete) work is now to always use the oldest decl,
>> adding information from later ones as necessary.  Cases where that
>> does not happen are bugs - the bugs I've been trying to fix; the whole
>> problem is that the middle end is not prepared to cope with multiple
>> DECLs for the same object.
>
> That does sound like a good plan.  The difficulty will be in ensuring
> that the newer decl is not used before duplicate_decls is called on
> the pair of decls; in particular, this will require some changes to
> IMA, merge_translation_unit_decls will need to go away because
> duplicate_decls will have to be called when the decl is seen rather
> than later on.  I've wanted to do this ever since we removed the GCC
> extension that made it necessary to do this as a final pass, but don't
> have time right now.
>
> Is this going to be necessary for 3.4?  It sounds like a lot of work
> very late in the release cycle.  It may be better to have the
> middle-end compare DECL_ASSEMBLER_NAME for 3.4 and make these changes
> in 3.5.
>
> (I've added Dale since he was struggling with a related problem in the
> tree-ssa branch, and neither he nor I knew about this new requirement
> for 'one DECL' in the backend.)

Thanks.  The problem I'm struggling with involves use of mutliple 
TYPE_DECL nodes
for "the same" type multiply defined in different files.  Geoff has 
posted an example
showing that compatibility of types is not transitive in C99, which I 
believe
implies you can't unify all the compatible types into one node, and 
further implies
that comparisons for type compatibility can't just test for pointer 
equality, as they
do now in many places in tree-ssa.  This is a mess; beyond the 
correctness problem,
going through the full rigamarole for type comparisons all the time has 
the potential
for introducing compile speed regressions.  I am thinking along the 
lines of keeping
a hash table or some such for remembering the result of type1=?=type2.