5 ms·

Others have gone down this path and realized it's not as easy as it sounds: http://blog.regehr.org/archives/1287 http://blog.regehr.org/archives/1287

mpweiher 10y ago
Yes, but it depends a lot what you consider "down this path". John's approach seemed to be to define the UB, and to me it looks like he found out why it was left as UB in the spec. Not exploiting the UB for optimizations in ways that break lots of code is actually trivially easy. We have been doing it for 30+ years and we just have to stop adding new optimizations that break, and possibly revert some of the ones that are already in there.
- gpderetta 10y ago
  > Not exploiting the UB for optimizations in ways that break lots of code is actually trivially easy Here lies madness. What optimizations are not allowed exactly? Strict aliasing? Assuming dereferenced pointers are not null? Assuming all array accesses are always in bound? Assuming that integers don't wrap? Assuming that allocated memory is not accessed after a free? Reusing function frame slots of variables with non overlapping lifetimes? Not laying down local variables in the most obvious way? Caching and reordering non-volatile memory accesses? Accessing local variables of functions that have returned? I'm sure you will say obviously not allowed to the first few and obviously allowed to the last few, but at some point all of these optimizations (and more) did break some code as some point.
  - mpweiher 10y ago
    > Here lies madness. Nah. You're looking at it the wrong way. You are saying madness lies in going there. We don't have to "go there". We can simply not leave there. Not doing something is easy. In fact, it's my secret super-power. If you want, I'd be happy to teach you.
    - haberman 10y ago
      Compilers already have these optimizations. Doing nothing would be leaving those optimizations in. If what you want is a straightforward translation of C into machine code, there is always -O0.
      - mpweiher 10y ago
        > Compilers already have these optimizations. git co <previous-hash> You're welcome!
        haberman 10y ago
        You're the person who wants this. Maybe you should do that? Also make sure you're willing to give up support for newer language standards, CPU architectures, and countless bugfixes (even C++98 support was getting pretty noticeable bugfixes in GCC 10 years ago).

mpweiher 10y ago

Yes, but it depends a lot what you consider "down this path". John's approach seemed to be to define the UB, and to me it looks like he found out why it was left as UB in the spec. Not exploiting the UB for optimizations in ways that break lots of code is actually trivially easy. We have been doing it for 30+ years and we just have to stop adding new optimizations that break, and possibly revert some of the ones that are already in there.

gpderetta 10y ago
> Not exploiting the UB for optimizations in ways that break lots of code is actually trivially easy Here lies madness. What optimizations are not allowed exactly? Strict aliasing? Assuming dereferenced pointers are not null? Assuming all array accesses are always in bound? Assuming that integers don't wrap? Assuming that allocated memory is not accessed after a free? Reusing function frame slots of variables with non overlapping lifetimes? Not laying down local variables in the most obvious way? Caching and reordering non-volatile memory accesses? Accessing local variables of functions that have returned? I'm sure you will say obviously not allowed to the first few and obviously allowed to the last few, but at some point all of these optimizations (and more) did break some code as some point.
- mpweiher 10y ago
  > Here lies madness. Nah. You're looking at it the wrong way. You are saying madness lies in going there. We don't have to "go there". We can simply not leave there. Not doing something is easy. In fact, it's my secret super-power. If you want, I'd be happy to teach you.
  - haberman 10y ago
    Compilers already have these optimizations. Doing nothing would be leaving those optimizations in. If what you want is a straightforward translation of C into machine code, there is always -O0.
    - mpweiher 10y ago
      > Compilers already have these optimizations. git co <previous-hash> You're welcome!
      - haberman 10y ago
        You're the person who wants this. Maybe you should do that? Also make sure you're willing to give up support for newer language standards, CPU architectures, and countless bugfixes (even C++98 support was getting pretty noticeable bugfixes in GCC 10 years ago).