Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!think.com!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: Date: 19 Nov 90 16:22:31 GMT References: <5494:Nov1519:06:3790@kramden.acf.nyu.edu> <6063@lanl.gov> <9576:Nov1523:11:0990@kramden.acf.nyu.edu> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 27 In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 15 Nov 90 23:11:09 GMT In article <9576:Nov1523:11:0990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: | You want a specific example? Were you reading this group when somebody | pointed out how Sun's optimizer couldn't produce even near-optimal code | for a simple loop through an array? Matt pointed out that gcc did much | better. gcc, however, will produce suboptimal code for | | for (j = 0;j < 100;j++) | a[i * j] = ...; | | As you now understand, no optimizer will handle all cases. For any | optimizer you show me, there exists array code that it can't convert | into pointer code as well as possible. What matters in practice is that | real optimizers trip up on such simple code. Even good Fortran | optimizers don't do very well on moderately complex code. GCC does do the optimization on the MIPS (providing you use strength reduction). I suspect the array a was an integer array, since the Sparc does not have an integer multiplication, gcc internally turned the thing into calling __mulsi3, which it no longer reconizes as a multiply. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?