This is the mail archive of the gcc-patches@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: Final intermodule patch


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.

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
consist of keeping track of context so that we new which .s file to
write things into.  It's probably work that would benefit the
compile-server project, as well -- perhaps eventually it would even be
possible to compile several files at once in separate threads, or some
such.

In fact, what I suggest is what has been done in analogous situations in
the past by others, although I am not permitted to provide references.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC


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