[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: NTH-VALUE (Version 4)
- To: peck@Sun.COM
- Subject: Issue: NTH-VALUE (Version 4)
- From: Jon L White <jonl@lucid.com>
- Date: Sun, 15 Jan 89 06:14:08 PST
- Cc: SEB1525@draper.com, cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: peck@Sun.COM's message of Fri, 13 Jan 89 13:20:35 PST <8901132120.AA11212@denali.sun.com>
re: . . . FLOOR would have to be able
â??â??â??â??â??â??â??â??â??â??â??â??â??
>to tell, for example, that only its second value was going to get used,
>and avoid computing the first value. This may not make a lot of sense
>for FLOOR, but there may be other functions where it does.
A really smart compiler that is working on an inline function that it
knows a LOT about *maybe* would make such an optimzation.
Lucid's 3.0 compiler "knows" a lot about FLOOR, and indeed optimizes
cases when only the first value is returned. This turnes out to be
extrememly important for floating point FLOOR's. This is moderately
easy to do in a compiler that has implemented type-propogation, since it
has to be aware of multiple-value contexts anyway. But it would be
significantly harder to optimize the case where only the second argument
is ultimately used, since there are so many more ways to obscure that fact.
The truncatation (no pun intended) of multiple values down into one is a
very common case -- specified at length in CLtL -- and is syntatically
easy to detect.
-- JonL --