11 ms·

I don't think the linux kernel is a good example. They define their own internal ABI. There are no libraries. They don't try to be portable to exotic compilers,

I don't think the linux kernel is a good example. They define their own internal ABI. There are no libraries. They don't try to be portable to exotic compilers, in fact only GCC is officially supported. They even get to opt out of things like signed overflow being undefined behavior.

Gibbon1 6y ago
Well signed overflow being undefined is something that needs to be fixed.
- saagarjha 6y ago
  Signed overflow being undefined enables a broad range of loop optimizations in a language that has no other way of allowing these to exist.
  - inetknght 6y ago
    Signed overflow should be defined and a platform that provides a normal int which has different overflow behavior should have their int named different. Maybe noverflowed_int or
    - saagarjha 6y ago
      Again, this would kill many loop optimizations.
      - inetknght 6y ago
        No it wouldn't. It would mean loop optimizations shouldn't use `int` as it's defined. It means they should use whatever other integer type _does_ do what the optimization wants. And if that means creating a new integer type then so be it.
    - Gibbon1 6y ago
      Exactly, if the coder thinks those optimizations will buy him anything then let them enable them for that one case. And stop pretending that micro benchmarks matter for the rest of the 99.9% of code out there. Last time I looked at the speedup you got from loop optimization it at most a few percent for a very simple loop. For a loop that has some meat it'd be noise.
      - fooker 6y ago
        > Last time I looked at the speedup you got from loop optimization it at most a few percent for a very simple loop. Wow, no. Most loop optimizations make loops significantly faster, even an order of magnitude is not uncommon. Write a few loops and compare the code generated by any compiler with O0 vs O3.
    - UncleMeat 6y ago
      Defining signed overflow requires sticking more instructions for every integer addition, since the platform is not guaranteed to actually overflow when you want it to so the program will have to detect this and force the overflow to happen. Major slowdowns. Lots of loop stuff also depends on non-overflowing signed integers. If integers can shrink on addition then you cannot safely do a lot of unrolling or fancier stuff based on affine loop transformations.
      - jcranmer 6y ago
        > Defining signed overflow requires sticking more instructions for every integer addition, since the platform is not guaranteed to actually overflow when you want it to so the program will have to detect this and force the overflow to happen. Major slowdowns. That is most definitely not true. All modern hardware is 2's complement arithmetic, and the corresponding signed integer arithmetic operation will silently overflow without complaint. > Lots of loop stuff also depends on non-overflowing signed integers. If integers can shrink on addition then you cannot safely do a lot of unrolling or fancier stuff based on affine loop transformations. Not really. Only certain particular patterns force weirdness on loops were overflow well-defined, and these aren't the most common pattern (a basic for (int i = 0; i < N; i++) loop doesn't need overflow to be undefined to have loop optimizations kick in). Even if you hit a case where it can be annoying (such as the poor man's multidimensional array access, because C lacks such niceties), you can multiversion the loop to fall back to an unoptimized loop in cases where overflow would have kicked in and otherwise use the optimized loop. Where I've seen the most issues with signed versus unsigned is when LLVM decides to take a loop with a signed 32-bit index, promote the index variable to 64-bit (using zero-extension for all the related values), and then retain a signed 32-bit comparison for the loop bound. The unsigned version of the code had fewer problems. So much for signed overflow being good for optimizations.
        UncleMeat 6y ago
        > All modern hardware is 2's complement arithmetic, and the corresponding signed integer arithmetic operation will silently overflow without complaint. But not the same width. Does it overflow at 32bits or 64? If you define it as one or the other, that requires a runtime check.

Gibbon1 6y ago

Well signed overflow being undefined is something that needs to be fixed.

saagarjha 6y ago
Signed overflow being undefined enables a broad range of loop optimizations in a language that has no other way of allowing these to exist.
- inetknght 6y ago
  Signed overflow should be defined and a platform that provides a normal int which has different overflow behavior should have their int named different. Maybe noverflowed_int or
  - saagarjha 6y ago
    Again, this would kill many loop optimizations.
    - inetknght 6y ago
      No it wouldn't. It would mean loop optimizations shouldn't use `int` as it's defined. It means they should use whatever other integer type _does_ do what the optimization wants. And if that means creating a new integer type then so be it.
  - Gibbon1 6y ago
    Exactly, if the coder thinks those optimizations will buy him anything then let them enable them for that one case. And stop pretending that micro benchmarks matter for the rest of the 99.9% of code out there. Last time I looked at the speedup you got from loop optimization it at most a few percent for a very simple loop. For a loop that has some meat it'd be noise.
    - fooker 6y ago
      > Last time I looked at the speedup you got from loop optimization it at most a few percent for a very simple loop. Wow, no. Most loop optimizations make loops significantly faster, even an order of magnitude is not uncommon. Write a few loops and compare the code generated by any compiler with O0 vs O3.
  - UncleMeat 6y ago
    Defining signed overflow requires sticking more instructions for every integer addition, since the platform is not guaranteed to actually overflow when you want it to so the program will have to detect this and force the overflow to happen. Major slowdowns. Lots of loop stuff also depends on non-overflowing signed integers. If integers can shrink on addition then you cannot safely do a lot of unrolling or fancier stuff based on affine loop transformations.
    - jcranmer 6y ago
      > Defining signed overflow requires sticking more instructions for every integer addition, since the platform is not guaranteed to actually overflow when you want it to so the program will have to detect this and force the overflow to happen. Major slowdowns. That is most definitely not true. All modern hardware is 2's complement arithmetic, and the corresponding signed integer arithmetic operation will silently overflow without complaint. > Lots of loop stuff also depends on non-overflowing signed integers. If integers can shrink on addition then you cannot safely do a lot of unrolling or fancier stuff based on affine loop transformations. Not really. Only certain particular patterns force weirdness on loops were overflow well-defined, and these aren't the most common pattern (a basic for (int i = 0; i < N; i++) loop doesn't need overflow to be undefined to have loop optimizations kick in). Even if you hit a case where it can be annoying (such as the poor man's multidimensional array access, because C lacks such niceties), you can multiversion the loop to fall back to an unoptimized loop in cases where overflow would have kicked in and otherwise use the optimized loop. Where I've seen the most issues with signed versus unsigned is when LLVM decides to take a loop with a signed 32-bit index, promote the index variable to 64-bit (using zero-extension for all the related values), and then retain a signed 32-bit comparison for the loop bound. The unsigned version of the code had fewer problems. So much for signed overflow being good for optimizations.
      - UncleMeat 6y ago
        > All modern hardware is 2's complement arithmetic, and the corresponding signed integer arithmetic operation will silently overflow without complaint. But not the same width. Does it overflow at 32bits or 64? If you define it as one or the other, that requires a runtime check.