It's not that easy. You can't predict where infinite loops will show up in the face of the halting problem. LLVM needs to be fixed not to exploit this UB when it sees it. Even for C and C++, they disagree whether this is language-level UB
-
-
I'm often curious what's the subset of programs that gets faster via this UB and how much of that gain can be gotten back by beefing up some loop analyses a bit
1 reply 0 retweets 4 likes -
Replying to @johnregehr @jckarter and
anyway this behavior as the LLVM-level default obviously needs to die, it's a crappy thing to have inherited from being a dedicated C/C++ IR
1 reply 0 retweets 3 likes -
It doesn’t even make sense from that legacy’s standpoint. The standards are pretty clear about what forward progress means, so the frontends can mark infinite loops themselves.
1 reply 0 retweets 1 like -
the issue isn't infinite loops but potentially infinite loops. a frontend, lacking deep static analysis, would need to mark basically every loop as potentially infinite.
2 replies 0 retweets 2 likes -
Would you get most of the benefit by saying that infinite loops without side effects may only trap or run forever? Seems like you could let a compiler optimize down to traps without letting it go all the way to UB
1 reply 0 retweets 0 likes -
this is the best explanation I know of: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm … I don't think traps help us here. it really just comes down to who gets hurt by switching the default, and if we care about that.
2 replies 0 retweets 1 like -
Replying to @johnregehr @jckarter and
my opinion is that right now, today we switch the default and hide a few optimiziations behind a "provably terminates " attribute and anyone who has a problem with this gets to write loop analyses that add this attribute
1 reply 0 retweets 2 likes -
Replying to @johnregehr @jckarter and
Don’t we have this discussion like every year and the consensus is “yeah, let’s fix this behavior in LLVM” and then nobody does
2 replies 1 retweet 14 likes -
Replying to @pcwalton @johnregehr and
“Let’s fix the bug in LLVM…by rewriting everything to use Cranelift”
2 replies 0 retweets 8 likes
I’m still a bit unhappy about how our noalias bug fix patch got nitpicked by Daniel Berlin and then stalled out. :\
-
-
That’s a bummer. Try again?
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.