4 ms·
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approa
by revelation 9y ago
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.
- wyldfire 9y ago> reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.
- revelation 9y agoUBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.
- gpderetta 9y agoWhen the sanitizer is on, the optimizer (modulo bugs of course) does not remove the checks.
- deleted 9y ago[deleted]
- ajross 9y agoThat argument would make more sense if they actually were faster, which they often aren't. Last I checked (and I don't keep up with this, to be fair) they still lagged gcc on most macrobenchmarks on x86.
- davidcuddeback 9y ago> they still lagged gcc Isn't the "they" in this thread gcc, or did I misread something?
- ajross 9y agoI took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".
- davidcuddeback 9y agoOh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)
- wyldfire 9y agoSorry, I should've been more explicit when I responded to the original clang vs gcc comment. Note that UBSan is (mostly? totally? originally?) a Google project and it's been ported to both clang and gcc.
- skgoa 9y agoI mean, if you use GCC does recklessly optimize away (some) security/safety code. This is one of the reasons why we don't use it for code we ship. I work in a safety-conscious industry, where an overeager compiler can literally kill people.
- ensiferum 9y agoUmh.. the compiler writers don't "exploit undefined behaviour". The compiler writers write the compiler with the expectation that the program being compiled is correct i.e. to the specification. Now when the program fails to be correct, optimizations can result in "weird" results, which is not really incorrect since the input was incorrect.
- kllrnohj 9y ago> when I can narrow it down to a single offending function, that gets optnone slapped on it and done If you're able to narrow it down that far why not then fix your bug?
- revelation 9y agoWell, the last case I can recall where I had to resort to this used inline NEON assembly for what is essentially a fancy 2D memcpy. With optimization on textures were corrupted. I spent an hour diffing objdump output and got nowhere. Essentially, it was not worth more of my time to figure out how aggressive optimizations were breaking the parts of a memory bandwidth constrained function that aren't worth optimizing in the first place. For GCC inline assembly means "take your grubby hands off". For clang it's essentially an invitation to do whatever.
- kllrnohj 9y ago> For GCC inline assembly means "take your grubby hands off". For clang it's essentially an invitation to do whatever. That's not true at all. Clang respects the clobbers entry on inline assembly and does not do whatever it wants. See GCC's documentation on it: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobber... Based off of your description you probably just needed to add the "memory" clobber to tell the compiler that any registers it might have kept are no longer valid.
- deleted 9y ago[deleted]