This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Lazy allocation of DECL_ASSEMBLER_NAME



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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]