🚀 go-pugleaf

In article <PCG.90Sep4221859@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
<On 1 Sep 90 13:21:56 GMT, ark@alice.UUCP (Andrew Koenig) said:
<ark< One fairly easy to express such an optimization would be to say
<ark< that `if every return statement in a function returns the same
<ark< local variable, and that local variable has the same type as the
<ark< function's return value, then the compiler should alias the local
<ark< variable to the return value.'

Zortech C++ 2.1 does exactly this optimization. It actually turns out
to be less code in the compiler to implement the optimization rather
than implement the syntax for the named return value.

<This is a very good example of the divide between people like me and
<people who love compilers that take several hundred kilobytes of core.

ZTC++ is the smallest and fastest C++ compiler, by a wide margin.
(Yes, I'm throwing down the gauntlet!)

<A compiler can discover a large number of things by careful analysis of
<the source; in this case, by doing two passes over each function it can
<discover that it can alias a local variable to the return value slot on
<the stack or wherever it is.

A C++ compiler must do multiple passes anyway, in order to determine where
to put the destructors. (It actually scans a 'basic block' version of the
function in memory.)

<Now let me observe: what is the cost of telling the compiler beforehand?
<virtually none. What is the cost of letting the compiler discover it?
<large -- you have to make two passes over each function, and delay
<generating real code until the second pass, while you build a full in
<memory representation of the procedure in the first pass, in order to
<check whether you can alias or not.

This is necessary for C++ anyway. The extra overhead to do 'return value
optimization' is insignificant. (ZTC++ spends most of it's time
forming tokens and sitting inside malloc().)