Re: Problems with "ANSI aliasing" [was: Why C is much slower ..]

trt@cs.duke.edu (Thomas R. Truscott) writes:


> > -OPT:alias=typed
> >
> > TYPED or NO_TYPED TYPED specifies that pointers of
> > distinct base types are assumed to
> > point to distinct, non-overlapping
> > objects.


> This is a nice concept, but I think for this option to be usable
> in large-ish programs two more things are needed:
>
> (1) A variant (e.g -OPT:alias=typed_check) which generates
> a run-time check that the assumption above is correct.


Interesting, but if you are going to ask SGI to introduce this sort of
run-time check you should also encourage them to *correctly* implement
more mundane things like array bounds checking (in both Fortran and C;
their Fortran compilers claim to support it, but it is obvious to the
experienced user that a number of situations which should be checked
are not).


I'm also a little unclear as to what exactly you are proposing to
check. Surely you don't want to take *every* possible pair of
pointers of distinct base types and test it for overlap.


> With this, whenever the compiler takes advantage of alias=type it
> also adds code to trap if there is actually an overlap. The user
> can then run the program on various test inputs and gain some
> confidence that this optimization is safe.


Aha. I think such confidence would be misplaced. The optimisation may
be safe with one release of the compiler but break on the next because
of changes in how the compiler takes advantage of alias=typed.




> (2) A most conservative rule than what is stated above.


*More* conservative, surely?


> For starters, one should not assume that a "void *"
> can point only to an object of type void.


You forgot a smiley here.


> And similarly for "char *" and other pointers to objects of size 1,
> since people often use those rather than "void *".


Good C compilers tend to warn about such pointer type inconsistencies.


> Also, a pointer cast to another type should not be assumed
> to be distinct from the original pointer.


You are missing the point. If the code you are compiling relies on
pointer type casts, then -OPT:alias=typed is unsafe. Of course there
is C code out there for which this option is unsafe; that is why it
isn't turned on by default!


> Other vendors have similar "ANSI alias" options, and whenever I have
> tried them (on a large collection of software at the company where I
> work), problems have arisen. When I point out the specific problems
> to the vendors, they tell me to turn off the option. I have concluded
> from this that these options are intended to speed up benchmarks, not
> real programs.


I disagree. They are intended to speed up well-behaved programs. That
said, I think a source-level pragma to indicate the absence of
aliasing on a fine-grained, case-by case basis would be far more
useful than an all-or-nothing command line switch. One could use it to
speed up critical sections of the code. One could even use it safely,
by preceding every use with an explicit test that the target arrays
don't overlap. (One of the problems with C pointers is that one often
doesn't know where the object being pointed into begins or ends. One
could take a conservative stance and say that two pointers *might*
overlap if there is any overlap between the objects---be they named
targets or malloc()ed heap areas---they point into, but the programmer
usually has additional insight on how the pointers will be used and
can write a more precise test.) It is no accident that the C9X draft
standard is moving in a similar direction (a "restrict" keyword, or
something like that) and that one of Cray's first extensions to
Fortran was an "ignore vector dependencies" pragma (CDIR$ IVDEP).

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