Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!texbell!nuchat!uhnix1!crcc!lavaca.uh.edu!gem.mps.ohio-state.edu!usc!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: inline policy
Summary: Dynamic inlining can be done of the as output...
Message-ID: <1047@crcc.uh.edu>
Date: 10 Nov 89 15:54:44 GMT
Lines: 31


    A more reasonable approach (which unfortunately only a true compiler like
    G++ can implement) is to let the compiler generate the code on the fly
    for each potential inlined function and then
Message-ID: <1485@aber-cs.UUCP>
Date: 9 Nov 89 22:19:42 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 20

I was really astonished when I realized that the "peephole" optimizer in
the new System V 3.2 for the 386 does (by default!) inlining, based on an
analysis of the assembler code generated by the compiler. There is even
an option ("-y N") that allows you to tell the optimizer not to inline
code sections longer than N bytes (or instructions?).

A daring, but probably effective, approach, that is entirely source language
independent. Inlining the assembler code could of course be applied also to
cfront output.

An aside: I'd really be curious to see some description of that incredible
peephole optimizer. Inlining is just one of the hairy things it does. There
are newarly two dozen options to control various transformations, and none is
documented... For example, inlining creates problems with the use of the
alloca() procedure, and the way to disable it (or even the fact that inlining
is performed at all) is never mentioned.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk