Charles R Harris wrote:
>> Interesting article. I note that it is OK to alias pointers to the
> signed and unsigned versions of integer types, which is where I must
> have picked up my notions about length. I don't recall seeing any
> major bit of software that didn't use the -fno-strict-aliasing flag,
> as casting pointers around is one of the things C is(was) all about.
> So I was a bit surprised that Mike was recommending not doing so,
> although making the choice on a file by file basis might be useful for
> the optimizer.
Well, as for the case of Linus' comments on LKML, you have to take
things into context, I think: this is an article about programming the
Cell CPU on the PS3. And if there is one domain where performance
matters a lot, it is the video game domain, and the complexity of modern
video games is several orders higher than most HPC softwares (the 80/20
rule is mostly a fallacy in video games). So everything counts.
C99 introduces several rules related to aliasing, as mentioned in the
article, so I am not sure you can say that C point is about aliasing
pointers. Seeing what happens with strict aliasing on a file per file
basis would be interesting (for example, in the ufunc code: at this
point, there is no aliasing possible anymore I think).
It is also mentioned that a lot of code can be made "strict aliasing"
safe: I don't know how far we could go in numpy. It would be quite
difficult, I guess, because you would have to use special code path
depending on whether there is potential aliasing or not.
cheers,
David