Adds void @llvm.invariant(i1 %cond)
This adds the basic invariant intrinsic, noop lowering, and some basic properties:
- llvm.invariant(undef) and llvm.invariant(true) are dead
- llvm.invariant(false) is unreachable (this directly corresponds to the documented behavior of MSVC's __assume(0))
The intrinsic is tagged as writing arbitrarily, in order to maintain control dependencies. BasicAA has been updated, however, to return NoModRef for any particular location-based query so that we don't unnecessarily block code motion.
I wonder if this would be more clear spelled "llvm.assume.invariant" or just "llvm.assume".
I think we should provide some minimal guidance for FE authors here that essentially indicates that using this intrinsic is not without cost, and essentially shouldn't be used to either document basic mathematical invariants the compiler could deduce otherwise, or if the invariant holds little or no value to the optimizer.
If the condition is undef, aren't they unreachable?
|3–5 ↗||(On Diff #11590)|
Indent seems weird here. Use the more common 2-space indent?
With a couple of small changes mentioned inline, LGTM.
I'm not sure I really like my wording around 'free' above, but this is a starting point.
I understand why you're doing this, but it honestly feels like a bit of a hack. Is it possibly time to introduce a notion of control dependence that is not driven by memory access? This is essentially what you've written, but there might be a better way to factor it.
This doesn't need to be changed before submission, I'm just raising it for consideration and discussion.
I've noticed we have multiple isXIntrinsic functions scatter around the code base. We might want to think about - in a separate change - creating an isIntrinsic(IntrinsicID) function on CallSite.
Adding a comment on this case would be good. Particularly given that it required discussion to arrive at this being the right semantic.
This test could be stronger. Could you add a FileCheck here?
Good idea. Instead of "free", I'll say something like, "The optimizer might limit the transformations performed on values used by the intrinsic in order to preserve the instructions only used to form the intrinsic's input argument, and this might prove undesirable if the extra information provided by that intrinsic does cause sufficient overall improvement."
Fixing this is another major infrastructure project. :(
Good idea; I'll queue that for later refactoring.
No, this is a "generic lowering" test. It runs on all targets to make sure that it does not crash (that the code generator does *something*). You'll find many such tests in that directory.