3 ms·

I wish the author had dug a little deeper to see why this slowdown occurs. GCC seems to be generating an out-of-line function call to implement the trapped add

by nly 6y ago

I wish the author had dug a little deeper to see why this slowdown occurs. GCC seems to be generating an out-of-line function call to implement the trapped addition, which is going to inhibit a lot of other optimizations like vectorization: https://gcc.godbolt.org/z/zj6qbn https://gcc.godbolt.org/z/zj6qbn By contrast, Clang is not: https://gcc.godbolt.org/z/r7avno https://gcc.godbolt.org/z/r7avno Btw if you only need overflow checking in a few places, you can use overflow detecting intrinsics: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins... In C++, this is going to be way more useful than -ftrapv anyway, since in a lot of situations you're dealing with user input and you're probably going to want to throw, not abort. https://gcc.godbolt.org/z/5qvTf9 https://gcc.godbolt.org/z/5qvTf9

haberman 6y ago
From the article: > Looking at the assembly, I find that the clang compiler generates sensible code on x64 processor, with simple jumps added when the overflow is detected. Meanwhile, GCC seems to call poorly optimized runtime library functions.
- gumby 6y ago
  ...because he didn’t pass the correct options to gcc. Look at a comment parallel to yours for details.
  - teawrecks 6y ago
    I think it was more in response to, "I wish the author had dug a little deeper to see why this slowdown occurs."
colanderman 6y ago
Indeed. -ftrapv is no longer the best choice for overflow trapping in GCC anyway; in my experience it's pretty inconsistent handling e.g. compile-time overflows. -fsanitize=signed-integer-overflow (part of UBSAN) produces more efficient code, provides better coverage, and is more flexible. By default it provides a diagnostic message; you can instead simply abort with -fno-sanitize-recover, or execute an undefined instruction with -fsanitize-undefined-trap-on-error (equivalent to Clang's -ftrapv). Regardless of choice, addition is performed inline. See: https://gcc.godbolt.org/z/aGo6WW https://gcc.godbolt.org/z/aGo6WW

by nly 6y ago

haberman 6y ago

From the article: > Looking at the assembly, I find that the clang compiler generates sensible code on x64 processor, with simple jumps added when the overflow is detected. Meanwhile, GCC seems to call poorly optimized runtime library functions.

gumby 6y ago
...because he didn’t pass the correct options to gcc. Look at a comment parallel to yours for details.
- teawrecks 6y ago
  I think it was more in response to, "I wish the author had dug a little deeper to see why this slowdown occurs."

colanderman 6y ago

Indeed. -ftrapv is no longer the best choice for overflow trapping in GCC anyway; in my experience it's pretty inconsistent handling e.g. compile-time overflows. -fsanitize=signed-integer-overflow (part of UBSAN) produces more efficient code, provides better coverage, and is more flexible. By default it provides a diagnostic message; you can instead simply abort with -fno-sanitize-recover, or execute an undefined instruction with -fsanitize-undefined-trap-on-error (equivalent to Clang's -ftrapv). Regardless of choice, addition is performed inline. See: https://gcc.godbolt.org/z/aGo6WW https://gcc.godbolt.org/z/aGo6WW