Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!garcon!garcon.cso.uiuc.edu!grunwald From: grunwald@flute.cs.uiuc.edu Newsgroups: comp.arch Subject: Re: SUN procedure inlining(was i860 Dhrystones) Message-ID: Date: 4 Apr 89 23:57:06 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> <1356@auspex.auspex.com> <4641@pt.cs.cmu.edu> Sender: news@garcon.cso.uiuc.edu Distribution: na Organization: University of Illinois, Urbana-Champaign Lines: 18 In-reply-to: schmitz@fas.ri.cmu.edu's message of 4 Apr 89 14:07:31 GMT The inlining done by the Greenhills compiler could be done by a peep-hole phase, but it's unlikely. When you say strcpy(foo, "this is a string") Greenhills turns this into a block move, because it already knows the length of the string. This beats the pants of a ``move-until-null-byte'' loop. I noticed this when comparing greenhills C to Gnu C for the '386. For dhrystones (and a few other programs) this makes a big performance difference. For other programs, Gnu C was better than Greenhills (and, if I might add, more stable than the greenhills version we have). -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu