4 ms·

code patterns like this happen a lot and the optimization is worthwhile: https://www.youtube.com/watch?v=yG1OZ69H_-o&t=2359 https://www.youtube.com/watch?v=yG1O

• vyodaiken 8y ago
  Again: not a single study with a benchmark, just an anecdote that actually means the opposite of what is intended. The authors of Bzip had to write non-idiomatic code to prevent UB "optimization" from breaking their code, and this results in compiled code that may or may not be slower. Tip: fewer assembly instructions does not always mean faster execution in a pipelined processor. In fact, compiling with -fwrap probably would generate better code.
  • vinkelhake 8y ago
    Do you have an example (or maybe a published study) where -fwrapv generates better code?
    • vyodaiken 8y ago
      Do you have a single published study showing that the UB "optimizations" benefit real programs? I typed in the example code and current Clang generates exactly the same assembly for both u and not u integers - which is correct. So the problem he is describing is an error in Clang code generation that has since been fixed. Again: I have yet to see a serious attempt to validate the utility of UB "optimizations" - this video certainly does not contain any.
      • wolf550e 8y ago
        The generated code is not the same: https://godbolt.org/z/GkFGqe https://godbolt.org/z/GkFGqe
        • vyodaiken 8y ago
          But the purported massive difference of the video disappears on those versions too. So that's the big proof of the efficacy of UB driven "optimization" - one additional assembler instruction in the clang code, some movslq vs movl. Dramatic. A micro-benchmark that indicates zero.