Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!mjs
From: mjs@hpfcso.HP.COM (Marc Sabatella)
Newsgroups: comp.lang.misc
Subject: Re: s
Message-ID: <8960019@hpfcso.HP.COM>
Date: 29 Oct 90 19:03:23 GMT
References: <66259@lanl.gov>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 36

>I do not!  I refuse to acknowledge that this optimization is the
>exclusive province of pointers!  If you can precompute the index, the
>compiler can apply the data flow graph to find the _use_ of the index
>and _always_ add the array base address - at _exactly_ the same point
>that _you_ would manually precompute the pointer (or anywhere in
>between - where ever is most efficient).  I personally find that the
>compiler's ability to do this saves me a lot of drudgery.

	int array[100];
	int *p;
	extern int *bar();

	foo ()
	{
		p = bar();
		*p = 42;
	}

versus

	int array[100];
	int i;
	extern int bar();

	foo ()
	{
		i = bar();
		array[i] = 42;
	}

Tough to get code for foo() in the second case to be as good as code in the
first case without more interprocedural data flow analysis than most compilers
are capable of.  Especially if we extend the problem and let "p" optionally
point into either of two arrays, where "bar" reads from stdin to determine
which array to point into.  Bad code design?  Possibly.  But don't make the
claim that indices can always be as efficient as pointers.