I'm not arguing that what Clang and GCC currently do is correct, but I am saying that they currently do it, and that it's likely to become officially correct *because* they want to it. Type-based alias analysis is similar. They tried to allow it, and will readjust it as needed.
Conversation
Type-based alias analysis is possible to specify consistently, and has clear reasons you want to do it. This provenance stuff has absolutely no motivation, because deriving pointers from ints/reprs is rare, and when you do it, you actually mean it.
2
1
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.
1
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.
Similarly, they could turn `pure_may_not_return(5); pure_may_not_return(5);` into a single call, since they are known to not depend on any external state and the same state is passed to them (just like they do with unwinding already).
1
It's just not really correct to think that the compilers are actually based on consistent logic. They deliberately do things that are logically wrong. C11 didn't make infinite loops undefined but rather some 'may be assumed [...] to terminate' so they are inconsistently behaved.
1
1
Show replies
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.
1
2
Show replies