|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-04-18)|
|Re: Why C is much slower than Fortran email@example.com (Thomas Elken) (1999-04-29)|
|Problems with "ANSI aliasing" [was: Why C is much slower ..] firstname.lastname@example.org (1999-04-30)|
|Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] email@example.com (1999-05-03)|
|Re: Problems with "ANSI aliasing" [was: Why C is much slower ..] firstname.lastname@example.org (1999-05-07)|
|From:||email@example.com (Thomas R. Truscott)|
|Date:||30 Apr 1999 22:50:35 -0400|
|Organization:||SAS Institute Inc.|
|References:||<3710584B.1C0F05F5@hotmail.com> <7etenl$nk5$1@alexander.INS.CWRU.Edu> 99-04-048 99-04-105|
|Keywords:||C, Fortran, performance|
> -Ofast is really a bundle of compiler options:
> The important one for this discussion is:
> TYPED or NO_TYPED TYPED specifies that pointers of
> distinct base types are assumed to
> point to distinct, non-overlapping
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.
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.
(2) A most conservative rule than what is stated above.
For starters, one should not assume that a "void *"
can point only to an object of type void.
And similarly for "char *" and other pointers to objects of size 1,
since people often use those rather than "void *".
Also, a pointer cast to another type should not be assumed
to be distinct from the original pointer. An artificial example:
foo = 1;
if (*(short *)&foo == 1)
The base type of &foo is long, and the base type of (short *) is
short, so by the rule above the compiler may assume they point to
distinct non-overlapping objects. In particular the compiler is free
move the assignment "foo = 1;" after the "if" statement, or as an
extra optimization it might declare the assignment dead and eliminate
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
Return to the
Search the comp.compilers archives again.