cross-module inlining (was Re: using gcj for a different language - is it possible?)

Mon Feb 9 16:27:00 GMT 2004

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.
> > 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."
Sounds like the preferred policy will be indirect dispatch (binary
compatibility) everywhere. 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.
(That said, I realize many popular gcj projects like RHUG tend to build
everything as a DSO, so Tom and I aren't necessarily in disagreement.)
Jeff