<![CDATA[Mesa and strict aliasing]]>I recently started poking at the Mesa source code. Presently Mesa builds with “-fno-strict-aliasing” by default, and removing that option produces a non-working binary. I started looking into this and just recently have submitted (the second version of) a patch to address some of the aliasing problems – enough that I could build a working binary with strict aliasing enabled:

http://lists.freedesktop.org/archives/mesa-dev/2015-June/087278.html

I don’t know whether this will be taken on board; at the time of writing, no-one has formally reviewed it or agreed to push it upstream. The performance improvement when compiling with vs without -fno-strict-aliasing is, admittedly, a bit underwhelming (less than I had hoped for, anyway); however, I personally feel that code requiring strict aliasing to be turned off is broken anyway.

Not everyone thinks that way, though. It’s clear that Ian Romanick, a prominent Mesa developer, did not (originally) even understand the issue:

NAK.  The datastructure is correct as-is.  It has been in common use since at least 1985.  See the references in the header file.

(The data structure is indeed correct; the implementation is broken unless strict aliasing is disabled). I don’t think it’s uncommon that C developers don’t properly understand the aliasing rules, but that’s a shame. The rules aren’t really that complicated. I liked this quote from Dave Airlie, another Mesa developer:

I personally think we should get past the, aliasing is hard, lets go shopping,

Or in other words: let’s stop using -fno-strict-aliasing as a crutch and just fix the problems. I’m glad that I’m not the only one with this opinion. A few other developers, however, clearly feel that it is too difficult, and that -fno-strict-aliasing is the answer. It’ll be interesting to see how this plays out.

]]>