Re: Unsafe Optimizations (formerly Compiler Design in C...)

pardo@june.cs.washington.edu (David Keppel)
Fri, 15 Jun 90 05:13:49 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) larus@primost.cs.wisc.edu (1990-06-14)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grover@brahmand.Eng.Sun.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) holub@violet.Berkeley.EDU (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) barmar@Think.COM (1990-06-15)
Re: Unsafe Optimizations (formerly Compiler Design in C...) henry@zoo.toronto.edu (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) dan@kfw.com (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chip@tct.uucp (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) grunwald@foobar.Colorado.EDU (Dirk Grunwald) (1990-06-20)
Re: Unsafe Optimizations (formerly Compiler Design in C...) marti@inf.ethz.ch (1990-06-21)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: pardo@june.cs.washington.edu (David Keppel)
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun13.143951.2129@esegue.segue.boston.ma.us>
Date: Fri, 15 Jun 90 05:13:49 GMT
Organization: University of Washington, Computer Science, Seattle
Keywords: code, optimize

This started out as a fast vs. safe debate. I'll digress left.


moss@cs.umass.edu (Eliot Moss) writes:
>[There are optimizations that will transform a[i] to *a forms.]


And indeed, there are machines on which the cannonical strcpy


char *
        strcpy (char *d, char const *s)
        {
char *orig = d;
while (*d++ = *s++)
; /* VOID */
return (orig);
        }


is faster as


char *
        strcpy (char *d, char const *s)
        {
int i = 0;
while (d[i] = s[i])
++i;
return (d);
        }


The MIPS R{2,3}000 spring to mind. In fact, so does the 80386, or anything
else that isn't VAXish. A moment's consideration should (hopefully) convince
you that the first form requires two increments per iteration, while the
latter requires only one. The only case when the first is cheaper is when
two pointer increments are cheaper than one integer increment. The point
being that pointer arith. isn't always a win.


;-D on ( Poineters and patience ) Pardo
--
pardo@cs.washington.edu
        {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.