This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: cross-module inlining (was Re: using gcj for a different language- is it possible?)
Jeff Sturm writes:
> On Mon, 9 Feb 2004, Andrew Haley wrote:
> > > I've been thinking a little about this since it can restrict inlining,
> > > escape analysis, and any other sort of useful IPA gcj might perform.
> >
> > If you want to do IPA, compile the files at the same time, and this
> > gives gcj carte blanche to do any optimizations it can find, including
> > full inlining. Separate compilation, however, implies binary
> > compatibility.
>
> Yes. Well, almost. I don't think gcj should have carte blanche
> when building a library, unless it continues to disallow class
> replacement at runtime.
Well, compiling everything together rather implies that, because calls
can be made directly between classes. Anyone who really wants to
replace an individual class in a library at runtime had better not
compile a whole library with -O3. But that's up to them.
> > > Similarly in Java, why not leave the most aggressive optimizations
> > > for the main executable (non-PIC) and stick to conservative
> > > binary-compatible optimizations for libraries? Does binary
> > > compatibility really matter for non-library code?
> >
> > That's up to the user, surely. I don't think we need to have any
> > particular policy here.
>
> Going back to the OP:
>
> "We're sort of moving away from doing inlining by default, since that
> breaks binary compatibility."
That was what I was disagreeing with. We have never inlined by
default, only with -O3, and only in a single compilation.
> Sounds like the preferred policy will be indirect dispatch (binary
> compatibility) everywhere.
The default policy, yes. By default we comply with the JLS.
> My simple suggestion is that indirect dispatch is really only
> needed for libraries, and by default more aggressive IPA can be
> done for classes compiled into the main executable.
No, that's wrong. You build an executable from a number of objects.
You don't want to have to recompile all its callers whan a class
changes. This is true whether the class is in a library or not.
Surely our default should be compliance with the JLS.
Andrew.