Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.arch
Subject: Re: SUN procedure inlining(was i860 Dhrystones)
Message-ID: <1356@auspex.auspex.com>
Date: 1 Apr 89 07:21:27 GMT
References: <39388@oliveb.olivetti.com> <15475@winchester.mips.COM> <95013@sun.Eng.Sun.COM> <13641@jumbo.dec.com> <95215@sun.Eng.Sun.COM> <4614@pt.cs.cmu.edu>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 29

>>>Results for the Sun-3/60 are not reported because the data in
>>>[Presentation on Benchmarks given at Sun User Group Conference, Dec 5-7,
>>>1988 by Sun Microsystems, Inc.] uses compiler optimization level 4 which
>>>employs procedure inlining.
>>
>>FYI, this is incorrect.  Current Sun C compilers do not perform procedure
>>inlining at any optimization level.
>
>Maybe you should look again

No, there's not much point in looking again; David is talking about
*general* procedure inlining, which the current Sun compilers do not do,
at least not to the best of my knowledge - a second look will almost
certainly confirm that.  This is quite different from the very
specialized inlining that the "inline" program performs (as I remember,
it performs inlining on the assembly-language output from the compiler),
so if the claim is that the 3/60 results used general procedure
inlining, the claim seems suspicious to me.  The only ".il" files I
could find on any of the 4.0 machines around here (both 68K and SPARC)
are 1) files for "libm" - in several flavors for the 68K machines - and
2) some for doing loads from possibly-misaligned locations. 

As far as I know, Dhrystone (the benchmark to which the comment about
the 3/60 refers) doesn't make heavy use of floating point (it's supposed
to be a synthetic systems programming benchmark, and systems programming
tends not to make heavy use of floating point) or the math library (if
it makes any use of it at all); furthermore, the 3/60 doesn't make use
of SPARC templates for handling misaligned data (it can handle it on its
own).  As such, "inline" is completely irrelevant to the discussion.