strict aliasing?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

strict aliasing?

Neal Becker
Is it safe to compile numpy with gcc 'strict aliasing'?

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: strict aliasing?

Andreas Klöckner-3
On Sonntag 04 Mai 2008, Neal Becker wrote:
> Is it safe to compile numpy with gcc 'strict aliasing'?

It seems that numpy (and most other Python-related C code) would constantly be
casting back and forth between PyObject * and PyArrayObject * (and others).
Does strict aliasing allow that, as long as each struct member is only ever
accessed through one type?

Andreas

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: strict aliasing?

Charles R Harris
In reply to this post by Neal Becker


On Sun, May 4, 2008 at 3:11 AM, Neal Becker <[hidden email]> wrote:
Is it safe to compile numpy with gcc 'strict aliasing'?

No!  And depending on the compiler version you might find whole bits of code disappearing during optimization without warning, yielding fantastic benchmarks but questionable results. The linux kernel won't compile correctly with that flag either, and it has been a longstanding cause of contention with gnu that it is the default. If you search the mailing lists you can find Linus making some nasty comments about it.

As far as I can tell, strict aliasing assumes that pointers are only cast between types of the same length. This is a problem in code that casts pointers with abandon between all types.

Chuck



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: strict aliasing?

cdavid
Charles R Harris wrote:

>
> As far as I can tell, strict aliasing assumes that pointers are only
> cast between types of the same length.

Strictly speaking, strict aliasing just says that locations pointed by
pointers do not alias. If you use two pointers of different types,
that's one case where the compiler will always assume they do not alias.
And this breaks heavily I think in numpy, where a lot of casting is
done, since internally a data buffer is a char*.

Converting from char* to any other type pointer often breaks the strict
aliasing rule:

http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html#cast_to_char_pointer

Using numscons with numpy trunk:

CFLAGS="-fstrict-aliasing -Wstrict-aliasing" python setupscons.py scons

certainly generate tons of warnings, and -Wstrict-aliasing does only
catch the most common ones. It is pretty safe to say it is not safe at
all :)

cheers,

David

_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: strict aliasing?

Charles R Harris
On Sun, May 4, 2008 at 11:16 PM, David Cournapeau <[hidden email]> wrote:
Charles R Harris wrote:

>
> As far as I can tell, strict aliasing assumes that pointers are only
> cast between types of the same length.

Strictly speaking, strict aliasing just says that locations pointed by
pointers do not alias. If you use two pointers of different types,
that's one case where the compiler will always assume they do not alias.

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. But the assumption of pointers and aliasing is so built into the whole C outlook that I wouldn't be surprised if any large program developed obscure bugs when compiled with the strict-aliasing flag.

Chuck


_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: strict aliasing?

cdavid
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion