Lazy allocation of DECL_ASSEMBLER_NAME

[Mark Mitchell]

>Inter-module analysis is very simple.  Trying to change decl handling
>in the compiler without thinking about the consequences of
>inter-module analysis: that's hard.
>  
>
Implementing inter-module analysis without thinking about the current 
known defects in the way the front end manages its symbol table is also 
hard. :-)

>What I did to implement IMA is to make the compiler handle multiple
>translation units in the same process.
>  
>
Yes, and that's a good thing. 

>>We'll likely break some aspects of inter-module optimization when we
>>fix some of the single translation-unit issues.  That is what we get
>>for collectively not agreeing on a single development plan.
>>    
>>
>
>I worry when I see statements like this.  I presume that by "break",
>you mean that "while working on these patches, some things will break,
>but of course those will be fixed before any patch is actually checked
>in, or as soon as possible afterwards if we didn't notice them before
>checkin", correct?
>
>  
>
Obviously, that would be the goal.

But, my feeling is that the intermodule stuff  was committed without as 
much planning as would have been ideal. 

I don't think this was your fault. 

You posted a message back on May 19th, and didn't get much in the way of 
comments.  In particular, I certainly did not comment -- I failed to see 
your patch.  Partly, that might be because it was only posted to 
gcc-patches -- there was no design discussion on gcc.  But there's no 
question that you made your early draft available for comment, and you 
didn't get much feedback, so I don't think anyone could possibly 
criticize you for proceeding with your plan.

But, there were lots of other balls in the air that are going to impact 
IMA.  We've talked for years about combining the C and C++ front ends, 
which would be a huge win from a maintenance standpoint, and would give 
a more consistent user-experience, but will make it difficult to keep 
IMA in its current form.  Zack's c-decl rewrite has been in progress for 
close to a year and is basically the only way to fix a number of bugs in 
C front end.  Those will likely impact IMA, and some of them may not 
have easy fixes.  All that information was out there in the community, 
but it never got fashioned into a coherent plan.  As a result, you 
checked in your changes, and now we've got obstacles on other fronts 
that might have been avoided.

My feeling is that we will at some point likely want to rewrite IMA 
support to address these issues and to make it a much more 
language-independent framework and to make it support multiple languages 
at once.  I think the current version is like my 
load-hoisting/store-sinking implementation: effective for some of the 
common cases, but not as general, maintainable, or powerful as one would 
like.  (Thankfully, my stuff will be dying soon, in favor of modern 
flow-graph oriented techniques!)

It may not be possible to do all this at once -- the new IMA support 
might need the new front end stuff, and the new front end stuff might 
not work with the old IMA, and so we'd have to either do the front end 
work first (temporarily breaking IMA), or we would have to make both 
sets of changes at once.

In the future, I'd really like to see design documents written up for 
these kinds of pervasive changes (PCH, IMA, combinging the C and C++ 
front ends, implementing "export", tree-ssa, compressed RTL, etc.) and 
posted to the GCC list *before* a patch is written and submitted.  After 
there's a patch, it's hard to change things, and it's almost impossible 
to go in a different direction once the patch has been checked in.

In the shorter term, what I hope and expect will happen is that you and 
Zack will collaborate to make the appropriate changes: changes to fix 
the C front end's various language-conformance bugs and changes to fix 
IMA accordingly.  None of that's going to happen in 3.4.0 -- and quite 
likely not in 3.4.x at all.  On the mainline, we can deal with some 
brief breakage as y'all work out the details of these changes.

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