6 ms·

Just a reminder that there are ZERO published studies showing that these UB "optimizations" have significant value for any real programs. They impose a bizarre

Just a reminder that there are ZERO published studies showing that these UB "optimizations" have significant value for any real programs. They impose a bizarre notion of C semantics that is not compatible with the language design. A good critique, for example, of the UB alias behavior can be found in Brian Kernhighans article on Pascal ( http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-pascal.html http://www.cs.virginia.edu/~evans/cs655-S00/readings/bwk-on-... ). The Standards authors have made the exact same error but in an ad hoc hacked up manner. Just use the flags that Linux has forced on the compiler developers in order to be able to make use of C or else give up on writing correct code. http://www.yodaiken.com/2018/11/17/standard-c-is-more-fun-than-ordinary-c/ http://www.yodaiken.com/2018/11/17/standard-c-is-more-fun-th...

wolf550e 8y ago
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=yG1OZ69H_-o&t=2359
- 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.
pcwalton 8y ago
> Just a reminder that there are ZERO published studies showing that these UB "optimizations" have significant value for any real programs. What? Sure there are. John Regehr publishes work in this area. https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf has performance numbers on taming some undefined behavior, for example (note the regressions). Anyway, only accepting "published studies" is pretty silly. UB is an engineering concern, not an academic one. Optimizations based on it arose because customers demanded them. Sometimes they can be quite significant: see https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759... for a good explanation of why signed overflow UB matters a lot for optimization of loops, for instance. There's this weird myth that compiler developers like implementing clever complicated optimizations just because they hate programmers or are trying to make busy work for themselves or something. Compiler developers, like other developers, don't like to do work for no reason. They implemented these optimizations because customers filed bug reports indicating "missed optimizations", and they needed to exploit undefined behavior to satisfy those customers.
- vyodaiken 8y ago
  You are joking, right? Regehr's paper covers a proposed CHANGE to Clang/LVM UB behavior, while I was asking for studies that show advantages of UB "optimization" itself. The numbers show minor changes of performance on an artificial benchmark - some better some worse. Try better. The absence of any actual studies showing benefits of UB "optimizations" is glaring. I don't care about motivations, which could simply be incompetance.
  - pcwalton 8y ago
    The point of giving that example is to show that there are studies that examine the benefit of undefined behavior, and in this case measure the performance of dialing back some degree of that UB exploitation. It's trivial to show that if you try to completely eliminate undefined behavior from the C language then performance will collapse. Even register allocation depends on exploiting undefined behavior—who's to say that some wild pointer you created didn't accidentally point to some local variable? The reason why you don't see any studies on it is that it's obvious. When it comes to signed overflow, the status quo comes from two inconvenient facts: (1) lots of C code out there loops over arrays using int for indices; (2) lots of C code out there assumes int is 32 bits. The latter means that, during the 64-bit transition, no compiler could switch to ILP64 and was forced to settle on LP64 (or LLP64 in the case of Windows). Confronted with these facts, compiler developers did the best they could, exploiting signed overflow in order to provide sensible codegen for idiomatic loops in C on 64-bit. The real world is complicated, and sometimes the right solution to an engineering problem is messy. Regarding the charge of incompetence, with all due respect, my friends who work on Clang and GCC are better programmers than 99% of commenters on this site.
userbinator 8y ago
They impose a bizarre notion of C semantics that is not compatible with the language design. Let's not forget that the standards committee even suggests "behaving during translation or program execution in a documented manner characteristic of the environment" (that's the exact wording from the standard) as one of the possible outcomes of UB, and it's the one that C programmers are most familiar with and also the one most aligned with the spirit of the language. Thus IMHO the blame falls entirely on the compiler authors for not making reasonable choices. The whole argument that UB makes for great optimisations is not supported by compilers like Intel's ICC, which has historically been much less likely to exploit UB, yet can generate far better code than GCC --- because it is much better at instruction selection/scheduling.
- vyodaiken 8y ago
  That's correct, but I fault the Standard committee for not rejecting the peculiar interpretation that allows Compiler developers to assume e.g. overflow does not happen while emitting code that does overflow.

wolf550e 8y ago

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=yG1OZ69H_-o&t=2359

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.

pcwalton 8y ago

> Just a reminder that there are ZERO published studies showing that these UB "optimizations" have significant value for any real programs. What? Sure there are. John Regehr publishes work in this area. https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf has performance numbers on taming some undefined behavior, for example (note the regressions). Anyway, only accepting "published studies" is pretty silly. UB is an engineering concern, not an academic one. Optimizations based on it arose because customers demanded them. Sometimes they can be quite significant: see https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759... for a good explanation of why signed overflow UB matters a lot for optimization of loops, for instance. There's this weird myth that compiler developers like implementing clever complicated optimizations just because they hate programmers or are trying to make busy work for themselves or something. Compiler developers, like other developers, don't like to do work for no reason. They implemented these optimizations because customers filed bug reports indicating "missed optimizations", and they needed to exploit undefined behavior to satisfy those customers.

vyodaiken 8y ago
You are joking, right? Regehr's paper covers a proposed CHANGE to Clang/LVM UB behavior, while I was asking for studies that show advantages of UB "optimization" itself. The numbers show minor changes of performance on an artificial benchmark - some better some worse. Try better. The absence of any actual studies showing benefits of UB "optimizations" is glaring. I don't care about motivations, which could simply be incompetance.
- pcwalton 8y ago
  The point of giving that example is to show that there are studies that examine the benefit of undefined behavior, and in this case measure the performance of dialing back some degree of that UB exploitation. It's trivial to show that if you try to completely eliminate undefined behavior from the C language then performance will collapse. Even register allocation depends on exploiting undefined behavior—who's to say that some wild pointer you created didn't accidentally point to some local variable? The reason why you don't see any studies on it is that it's obvious. When it comes to signed overflow, the status quo comes from two inconvenient facts: (1) lots of C code out there loops over arrays using int for indices; (2) lots of C code out there assumes int is 32 bits. The latter means that, during the 64-bit transition, no compiler could switch to ILP64 and was forced to settle on LP64 (or LLP64 in the case of Windows). Confronted with these facts, compiler developers did the best they could, exploiting signed overflow in order to provide sensible codegen for idiomatic loops in C on 64-bit. The real world is complicated, and sometimes the right solution to an engineering problem is messy. Regarding the charge of incompetence, with all due respect, my friends who work on Clang and GCC are better programmers than 99% of commenters on this site.

userbinator 8y ago

They impose a bizarre notion of C semantics that is not compatible with the language design. Let's not forget that the standards committee even suggests "behaving during translation or program execution in a documented manner characteristic of the environment" (that's the exact wording from the standard) as one of the possible outcomes of UB, and it's the one that C programmers are most familiar with and also the one most aligned with the spirit of the language. Thus IMHO the blame falls entirely on the compiler authors for not making reasonable choices. The whole argument that UB makes for great optimisations is not supported by compilers like Intel's ICC, which has historically been much less likely to exploit UB, yet can generate far better code than GCC --- because it is much better at instruction selection/scheduling.

vyodaiken 8y ago
That's correct, but I fault the Standard committee for not rejecting the peculiar interpretation that allows Compiler developers to assume e.g. overflow does not happen while emitting code that does overflow.