no noalias not negligible - a difference between C and Fortran - long
Doug Gwyn
gwyn at brl-smoke.ARPA
Sun May 22 00:56:47 AEST 1988
In article <54080 at sun.uucp> dgh%dgh at Sun.COM (David Hough) writes:
>Perhaps what will happen is that high-performance
>C compilers will adopt the questionable CDC/Cray Fortran practice
>of providing "unsafe" optimization levels that, for instance,
>assume all pointers are unaliased.
David's article did an excellent job of illustrating why many X3J11
members thought something like "noalias" would have been useful.
He correctly points out that ANSI C as it now stands requires that
aliasing be handled "right", and that this interferes with some
forms of optimization.
I think one of two possible "solutions" will be implemented by
vendors who care about this issue (for example, on vector hardware).
One is to adopt essentially "noalias", i.e. a type qualifier that
makes an appropriate guarantee so the optimizer is free to do its
thing (it would be best if this were "__noalias" or some other non-
conflicting extension to ANSI C). The other approach is to provide
a compiler switch to enable such optimization globally on a per-
source file basis. Both approaches are known to be viable; the
first is more general but requires more work on the part of the
programmer, and the resulting code is not strictly conforming.
It is even possible to support both methods simultaneously.
More information about the Comp.lang.c
mailing list