Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!uwm.edu!psuvax1!rutgers!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <14193@lambda.UUCP>
Date: 12 Jan 90 21:23:11 GMT
References: <21778@mimsy.umd.edu>
Distribution: na
Lines: 45

From article <21778@mimsy.umd.edu>, by chris@mimsy.umd.edu (Chris Torek):
> In article <14191@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
> -  z=1;
> -  *a=2;
> -  *b=1;
> 2) even when you cannot, this is false.  The generated code
>    would be `store 2 in register z', `store register z in *b',
>    `decreemnt register z', `store register z in *a'.

This doesn't do what the original code requires.  For one thing,
the original z wasn't a register.  For another, this code puts
the value 2 into *b and the number 1 into z and *a - so if no aliasing
is present, only z get its proper final value.  The only proper code
sequence for the original problem is 'load 1 (accumulator), store z,
increment, store *a, decrement, store *b' - which is one more instruction
than you want in the case where no aliasing has occurred.

Of course, if you machine had a method of storing immediate values directly
into memory (without registers at all), then the sequence could be done
efficiently without worrying about aliasing.  This is rarely the case, and
even so, the example is only a simplified example of how aliasing can
cause register scheduling problems - _real_code_ would present much more
complicated situations.

> [...] 
> ... and you would simply write
> 	#pragma nonintersecting a, b
> or something similar.

You could - if you had pragmas, if the compiler supported this particular
type of pragma, and if you were sure that neither *a nor *b pointed to
z (which isn't obvious from the example given).

> I refuse to read or respond to anything futher from jlg (at least for a few
> weeks); it is bad for my blood pressure.

I can understand that.  If you try to support an invalid position, 
it must get really difficult when you face someone that can detect
the bullsh*t.  

In any case, my original statement still stands -- I can't think of
any machines which don't suffer from inhibited optimization in the
presence of pointers.

J. Giles