open-std.org/jtc1/sc22/wg14 appears to be a more recent draft of what I linked earlier by the way. We'll see how they end up deciding to clarify it for C2X. My feeling is they will bend over backwards to permit / attempt to formalize existing real world compiler interpretations.
Conversation
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.
1
1
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.
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
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
Show replies