4 ms·

How historical is the importance of strict aliasing? AFAIU, strict aliasing survives not because of alignment issues when type punning, but because optimizing c

by wahern 3y ago

How historical is the importance of strict aliasing? AFAIU, strict aliasing survives not because of alignment issues when type punning, but because optimizing compilers heavily rely on non-aliasing to guarantee semantic correctness when reordering code, especially in and around loops. And the performance benefit of reordering has grown exponentially in lock-step with the emergence and increasing sophistication of superscalar architectures, pipelining, and cache hierarchies. Strict aliasing, IOW, is as a practical matter mostly about when and to what extent compilers (and sometimes processors) can optimize code through automatic reordering, much like wrt parallelism and memory barriers. In this sense, the role of strict aliasing is more important than it ever has been, and while technically "merely" a matter of performance (correctness could be obtained by completely abstaining from reordering), the performance of modern processors plummets precipitously when implicit hardware parallelism can't be fully leveraged.

JonChesterfield 3y ago
It's a hack from the days of separate compilation. Like lots of the "no diagnostic required" sucks to be you UB which can only be diagnosed at whole program link time. That is, the semantics and usability of modern C++ are compromised by the hardware capabilities of the machines on which C was first developed.
pkkm 3y ago
You're right that disabling strict aliasing removes some optimization opportunities for the compiler, but you can always get them back by adding restrict here and there. So it's really about what the default behavior should be. I'm thinking that it probably would've been better for the safe and intuitive behavior to be the default and for the extra optimization opportunities to be opt-in. A set of rules that usually does the right thing, but not always, can lull programmers into a false sense of security. Also, I'm not sure how true your argument is in practice. Modern compilers have other, more sophisticated ways to prove that things don't alias. A number of projects compile with -fno-strict-aliasing without using restrict very often, for example the Linux kernel, and they don't seem to suffer much from it. Linus has this to say about aliasing in kernel code: > In x86, I doubt _any_ amount of alias analysis makes a huge difference (as long as the compiler at least doesn't think that local variable spills can alias with anything else). Not enough registers, and generally pretty aggressively OoO (with alias analysis in hardware) makes for a much less sensitive platform.

by wahern 3y ago

JonChesterfield 3y ago

It's a hack from the days of separate compilation. Like lots of the "no diagnostic required" sucks to be you UB which can only be diagnosed at whole program link time. That is, the semantics and usability of modern C++ are compromised by the hardware capabilities of the machines on which C was first developed.

pkkm 3y ago

You're right that disabling strict aliasing removes some optimization opportunities for the compiler, but you can always get them back by adding restrict here and there. So it's really about what the default behavior should be. I'm thinking that it probably would've been better for the safe and intuitive behavior to be the default and for the extra optimization opportunities to be opt-in. A set of rules that usually does the right thing, but not always, can lull programmers into a false sense of security. Also, I'm not sure how true your argument is in practice. Modern compilers have other, more sophisticated ways to prove that things don't alias. A number of projects compile with -fno-strict-aliasing without using restrict very often, for example the Linux kernel, and they don't seem to suffer much from it. Linus has this to say about aliasing in kernel code: > In x86, I doubt _any_ amount of alias analysis makes a huge difference (as long as the compiler at least doesn't think that local variable spills can alias with anything else). Not enough registers, and generally pretty aggressively OoO (with alias analysis in hardware) makes for a much less sensitive platform.