[PATCH] D9375: An llvm.noalias intrinsic

[Daniel Berlin via llvm-commits]

dberlin added a comment.

In particular, note that recent issues with llvm.assume are precisely because it is defined as a construct with control flow scope, but is not itself part of control flow.

If instead, llvm.assume's semantics were like noalias, where it was "this intrinsic takes a value as a first argument, a condition as a second argument, and returns a value. Any use of the value it returns may assume the condition is true", it would not matter whether llvm.assume calls got hoisted or not, even all the way to right after the argument, the values being used would still have correct semantics.

(and the only way something could validly replace a non-assume value with an assume value is if it can prove the condition holds).

Of course, if the *goal* is to be able to have some scope in llvm that something holds, you need real control flow, and you just can't avoid this, and we shouldn't avoid it :P

The only solution i can see for that, and to actually have them try to define "scopes", is to either take the control flow as inputs to the lifetime markers, or attach it to existing control flow (IE lifetime start markers, assume, etc, can be properly thought of as attributes of either the top/bottom of a basic block, or an edge, depending how granular you want to be).

(These types of control flow intrinsics are much like having an analysis pass where you cheat because you don't want everything to have to do the work to preserve what you meant.  lifetime start/end are precisely like having dominator tree markers in the IR)


http://reviews.llvm.org/D9375