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

dan@kfw.com (Dan Mick)
Wed, 20 Jun 90 04:11:49 GMT

          From comp.compilers

Related articles
[5 earlier articles]
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)
Re: Unsafe Optimizations (formerly Compiler Design in C...) pardo@june.cs.washington.edu (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) kend%mrloog.wr.tek.com@RELAY.CS.NET (Ken Dickey) (1990-06-21)
Re: Unsafe Optimizations (formerly Compiler Design in C...) chittamu@dino.cs.umass.edu (1990-06-22)
[1 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: dan@kfw.com (Dan Mick)
References: <1990Jun12.163959.2593@esegue.segue.boston.ma.us> <1990Jun13.143951.2129@esegue.segue.boston.ma.us> <1990Jun15.051349.3016@esegue.segue.boston.ma.us>
Date: Wed, 20 Jun 90 04:11:49 GMT
Organization: KFW Corporation, Newbury Park, CA
Keywords: code, optimize

In article <1990Jun15.051349.3016@esegue.segue.boston.ma.us> pardo@june.cs.washington.edu (David Keppel) writes:
[speaking of *s++ = *p++ vs s[i] = p[i++]]


>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.


erm. I'm sure you realize, by now, that you also have two in-the-loop adds,
that may or may not be covered by a machine instruction, and that may or
may not be faster than the pointer adds, anyway. Don't forget that
[] is an add, no matter how you slice (or notate) it.
--


Post a followup to this message

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