4 ms·
Optimizing compilers have been around for yonks, sure, but I think taking aggressive advantage of UB is relatively recent. See e.g. Regehr in 2012 [1] : > The
by mrec 9y ago
Optimizing compilers have been around for yonks, sure, but I think taking aggressive advantage of UB is relatively recent. See e.g. Regehr in 2012 [1] :
> The current crop of C and C++ compilers will exploit undefined behaviors to generate efficient code [...], but not consistently or well. It’s time for us to take this seriously.
[1] https://blog.regehr.org/archives/761 https://blog.regehr.org/archives/761
- akvadrako 9y agoI see your comment is grey, so I guess people down-voted you and maybe you want to know why. It's because you are wrong. Compiler optimisations have always been relevant; even in the 90's they would omit entire blocks of code or reorder operations for example. I assume now it's more aggressive, because undefined behavior should never be relied upon. That's the point.
- mrec 9y agoI think you're reading me as saying something much stronger than what I actually meant. When we talk about C being "deceptive" we don't need to consider optimizations that respect the as-if rule. (Well, maybe when looking at the C->asm mapping or trying to benchmark, but that's not the level most people are working at.) The trend toward UB-based optimizations seems significant to me because they can and will take a bunch of C code which looks superficially reasonable, and which used to do X as intended, and suddenly (and perfectly legally) make it start doing Y instead. I assumed that's what barrkel was alluding to above. And yes, I'm sure there are old optimizations which will also do that, but basic things like hoisting and reordering and unrolling and dead-code elimination don't fall into that category.
- akvadrako 9y ago> And yes, I'm sure there are old optimizations which will also do that So then it's not new behavior.