Re: Final intermodule patch

[Jan Hubicka <jh at suse dot cz>]

> > On Sun, 2003-07-13 at 14:25, Jan Hubicka wrote:
> > > > Hi,
> > > > 
> > > > On 13 Jul 2003, Mark Mitchell wrote:
> > > > 
> > > > > The flawed aspect of the patch, in my opinion, is the attempt to output
> > > > > a single .s file from multiple input files.
> > > > 
> > > > [i.e. really the then necessary mangling of static entities]
> > > > 
> > > > In retrospective I must say that I agree with Mark here.  From a gcc user
> > > > perspective this would be quite surprising.  OTOH this bites only users
> > > > which actually use the intermodule capability.  I think this is an
> > > > optimization which is allowed to make debugging harder.
> > > > 
> > > > So while ideally this problem would be solved (by emitting different .s
> > > > files), I would also say that it's not that serious right now.  But given
> > > 
> > > Emitting different .s files does not seem to be very workable to me.
> > > Imagine that function A calls static B but itself gets inlined into C
> > > comming from other module.  Then the other module needs access the first
> > > module static symbol.  It is doable via globally visible aliases to
> > > static symbols but it is, hmm, ugly.
> > 
> > Ugliness, like beauty, is in the eye of the beholder.  
> > 
> > We should consider not just the implementation techniques, but the
> > user-visible impacts.  We should certainly also consider the
> > applicability of this new facility to situations like "export" and Java,
> > where generating a single object file is problemantic.  
> > 
> > In the case of "export", the current approach would result in multiply
> > defined symbols at link time because global entities present in both the
> > template and main translation unit would be emitted twice -- once when
> > you compiled the template, and once when you compiled the file that
> > instantiated the template.
> I don't understand why we can't simply get rid of the second copy of the
> symbols when we see we already assembled the template once
> In fact I would expect that for C++ we can save many of template
> instantiations in the compilation.
> > 
> > Workability is more objective than beauty, and I don't see why my
> > suggestion is unworkable.  It requires work, but much of the work would
> 
> Hmm, I must be still missing something.  How do you suggest to solve the
> problem of inlining infecting one module by accesses to static data in
> other modules?  It would be very bad if static accesses prevented
> intramodule inlining.
> 
> If I did fell that it just need extra work, I think I would not
> complain, but I don't see how it should work yet.
> Also I think it can be error prone when the resulting .o file would get
> linked in different contexts.
> And lastly I would like to get into function clonning busyness sometime
> in foreseable future.  In that case I will have two copies of the same
> function accessing the same static variables quite unavoidably.

OK,
I finally got it working by reverting your patch and see why you are
complaining.  The way of mangling everything is ineed ugly.  I didn't
read the patch closely enought to notice it.  THis also explains my
other email I sent about cgraphunit code correlation.

But mangling only in the case of duplicates as mentioned by Richard
sounds workable for me even tought it is not too easy as for instance
cgraph code currently requires DECL_ASSEMBLER_NAMEs to remain invariant
during compilation.

Honza
> 
> Honza