All the special cases they talk about in the draft are ill-defined and impossible to specify formally in a consistent manner. The people trying to do this have no idea what they're doing and it shows.
Conversation
That's true for a lot of the standard process including how they defined TBAA. Their decision that all side effect free loops can be assumed to terminate (unless the condition is a constant) is pretty messed up and Clang uses that to justify the issue I mentioned earlier.
1
1
Here is my usual test case for Clang:
gist.github.com/thestinger/139
Compile this with -O0 and it will infinite loop as it should. Compile it with -O2 and it won't. They've done this since long before standard allowed infinite loops to terminate and it doesn't allow this even now.
1
Removing the conditional return bypasses the issue because it makes the function get marked as noreturn which is treated as an effect. However, there is no concept of a function that may not return, and they assume that all non-noreturn functions will return to let them do it.
2
That's just how they do things. They are determined to do the optimization (removing calls to pure functions) and will do it, even before they have a way to do the optimization correctly. They will get the standard changed to permit things like it as needed too, when they aren't.
2
Non-idiotic solution is obvious: a function with an infinite loop is not pure.
1
Well they should have an always_returns attribute and they cannot simply remove calls to functions based on that not being present. They already handle this correctly in terms of unwinding. For example, pure_may_unwind(); pure_may_unwind(); will be optimized to 1 call, but not 0.
1
I don't think it'd even be that hard to add support for always_returns. There's just no one particularly interested in arguing for a new function attribute and implementing it in order to *constrain* existing optimizations to make them correct, rather than making code faster.
2
One observation from having had many conversations like this with you: your fatalism about things like this often seems exaggerated, and makes it hard to get anything productive out of these exchanges.
1
My perspective on it is based on bugs.llvm.org/show_bug.cgi?i breaking Rust, LLVM falsely justifying it based on C semantics (even though even the C11 semantics don't permit it) and then throwing some scraps at other languages that aren't acceptable to use: reviews.llvm.org/D38336.
The way the C standard ends up working is they can just take the shortcut of making everything undefined, even changing things to be *retroactively* undefined, and then other languages without that option using the same compilers are just completely screwed.
1
So for example, type-based alias analysis is important for other languages, but in those other languages it actually has to be a sound model / implementation or it can't be used. Similarly, the pointer provenance stuff is important to them, but it actually has to be sound too.
1
Show replies