This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
cross-module inlining (was Re: using gcj for a different language- is it possible?)
- From: Andrew Haley <aph at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, java at gcc dot gnu dot org
- Date: Mon, 9 Feb 2004 09:55:14 +0000
- Subject: cross-module inlining (was Re: using gcj for a different language- is it possible?)
- References: <878ykifbd2.fsf@fleche.redhat.com><Pine.LNX.4.44.0402082234300.18065-100000@ops2.one-point.com>
Jeff Sturm writes:
> On 8 Jan 2004, Tom Tromey wrote:
> > Offhand I don't remember what sort of inlining we can do. We're
> > sort of moving away from doing inlining by default, since that
> > breaks binary compatibility. But, yes, if the user asks for it,
> > gcj will inline methods, hopefully even across class boundaries.
>
> 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.
> 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.
Andrew.