no noalias not negligible - a difference between C and Fortran - long

[Walter Bright]

In article <1988May21.030207.25063 at light.uucp> bvs at light.UUCP (Bakul Shah) writes:
>#define overlap(x,y,n)    (!(x + n <= y || y + n <= x))
>	if (overlap(dx, dy, n))
>		return complain("overlapping arrays\n");
>Now a smart compiler can figure out that dx, dy don't overlap at the
>for-loop point and schedule load/stores or vectorize or whatever.

Current production optimizers only do flow analysis to the point that they
can determine if variable v is/isn't always a specific value at a specific
point in the program. Extending this to analyse for an open-ended list
of ranges for v such as:
	(c1 < v <= c2) || (c3 <= v < c4) || ...
would wind up being v-e-r-y s-l-o-w, a memory hog, and prone to lots of
bugs. Optimizers already are notorious for having strange bugs in them,
increasing the complexity of the flow analysis by a couple orders of
magnitude is impractical.

The most pragmatic solution is to simply bag the aliasing problem. Optimizers
should do what they can assuming worst case aliasing. Functions where
aliasing assumptions kill performance should be written in another language
(dare I say Fortran), and then linked in.

C shouldn't be force-fit to solve all applications. The aliasing problem
is only reasonably solved by changing the semantics of the language, i.e.
creating a different language.

BTW, I do all my coding in C and ASM. When I have speed problems with a
function in C, I recode it in ASM, and then use every trick I know. The
C version of the function is left in (but #if'd out) for
documentation/debugging purposes. (Some of my ASM subroutines wind up
as a page of the most convoluted stuff you've ever seen, but it really
flies!)