Adding my 2p On 19/02/19 17:54, Jason Orendorff wrote: >> My understanding is that the original purpose is that if you in a loop >> read from T* and write on each iteration via U* (where T and U differ >> by more than signedness and neither is char), without >> -fno-strict-aliasing the compiler doesn't need to pessimize on the >> assumption that a write via U* might change the next read via T*. With >> -fno-strict-aliasing, the compiler has to pessimize on the assumption >> that a write via U* might affect the next read via T*. The problem is >> that if accessing a T-typed value via U* is UB *in general*, who knows >> what *else* the compiler might do if -fno-strict-aliasing is not used >> and there are reinterpret_casts between pointer types, especially with >> LTO giving it a broader view to spot UB.
The most common issue I ran into when not using -fno-strict-aliasing on code with strict aliasing violations is that at high optimization levels the compiler reordered the memory accesses to the pointers that it assumed were not aliasing each other. Depending on the code and the types involved this can result in anything between an immediate (but confusing) crash or subtle data-corruption bugs. On the reverse I've seen performance regressions from using -fno-strict-aliasing only in tight loops where the inability to move accesses around was lengthening the critical path through the loop. However this was on processors with very limited memory reordering capabilities; my guess is that on today's hardware -fno-strict-aliasing's impact is lost in the noise. Gabriele
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
