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: Language-independent functions-as-trees representation


On Sun, 21 Jul 2002, Phil Edwards wrote:

> On Sun, Jul 21, 2002 at 04:22:28PM +0200, Andreas Jaeger wrote:
> > Pop Sébastian <pop@gauvain.u-strasbg.fr> writes:
> > > This would require to store SIMPLE trees comming from different front-ends
> > > then reconstruct a global tree. 
> > > (a little as the SGI's compiler works for interprocedural analysis, storing 
> > > WHIRL trees into .o files, then building the whole tree at link/optimize time).
> > 
> > It would only make sense with whole program optimizations for
> > interprocedural analysis.  Currently GCC does not do anything of this
> > kind but we should think forward and whole program optimizations is
> > something that some of us might want to see.
> 
> I was under the impression that this kind of whole-program IPA could only
> be done in the linker.  Or at least, in whatever tool is performing the
> role of the linker.

Only?
Certainly not, there are tons of ways to do it.
And it's not usually done "in" the linker.
The linker just calls the front/middle/back end (varies by compiler), 
with the names of all the objects, or, loads a shared lib and hands it 
the sections that contain the IPA data.

But as far as just inlining goes, you could do it without waiting till 
link time, it's just trickier (because you then have to make sure the 
trees you've stored are still up to date.  In the linker's case, you can 
assume the linker is only called once the objects are up-to-date.)
 > > 


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