6 ms·

> This is a woeful state of affairs propagated by an ill founded and widespread confidence that the C and C++ standards probably aren't as hostile to type alias

by pkkm 3y ago

> This is a woeful state of affairs propagated by an ill founded and widespread confidence that the C and C++ standards probably aren't as hostile to type aliasing as they actually are. Yep. Honestly, while I get the historical reasons for strict aliasing, I wish it hadn't been created. Just make -fno-strict-aliasing the default and normalize the abundant use of restrict, maybe shorten it to res or rest just like we use const instead of typing out constant. These implicit rules that usually, but not always, do what you want can be a bigger footgun than having to do things explicitly.

tialaramex 3y ago
> just like we use const instead of typing out constant. Those aren't constants†, they're immutable variables which are quite different. Because of the "as if" rule and provenance in some cases you get the same benefit as with a real constant, but that's not what this is. † In C or C++. In some other languages const does, logically, get you an actual constant.
- pkkm 3y ago
  Unless you think that the abbreviation const stands for some other word than constant, I'm not sure how that's relevant here?
  - tialaramex 3y ago
    Because these aren't actually constants it would actually be even worse if the keyword was "constant" rather than "const". Jargon that's identical to ordinary words but is just plain wrong if taken that way makes it harder to be understood. In a language where the const keyword gets you an actual constant this condition wouldn't arise.
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 pkkm 3y ago

tialaramex 3y ago

> just like we use const instead of typing out constant. Those aren't constants†, they're immutable variables which are quite different. Because of the "as if" rule and provenance in some cases you get the same benefit as with a real constant, but that's not what this is. † In C or C++. In some other languages const does, logically, get you an actual constant.

pkkm 3y ago
Unless you think that the abbreviation const stands for some other word than constant, I'm not sure how that's relevant here?
- tialaramex 3y ago
  Because these aren't actually constants it would actually be even worse if the keyword was "constant" rather than "const". Jargon that's identical to ordinary words but is just plain wrong if taken that way makes it harder to be understood. In a language where the const keyword gets you an actual constant this condition wouldn't arise.

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.