[PATCH] D11399: invariant.group and invariant.group.barrier docs

Richard Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 14 16:28:59 PDT 2015


rsmith added inline comments.

================
Comment at: docs/LangRef.rst:4430
@@ +4429,3 @@
+the optimizer that every ``load`` and ``store`` to the same pointer operand 
+within the same invariant group, can be assume to load or store the same bit 
+value (but see the ``llvm.invariant.group.barrier`` intrinsic which affects 
----------------
Prazek wrote:
> nlewycky wrote:
> > nlewycky wrote:
> > > "can be assume" --> "can be assumed"
> > What does it mean to be assumed to store the same bit value? In the case of loads I think it means that the load must return the same value. Is the store stating that the store must be storing the same value, that is the value operand of the two stores is bit equivalent?
> I don't understand what you are saying. It means that 2 stores with the same invariant.group and same operand must store the same value
Remove the word "bit" here, just "load or store the same value".

================
Comment at: docs/LangRef.rst:4444-4445
@@ +4443,4 @@
+   
+   %a = load i8, i8* %ptr, !invariant.group !0 ; Can assume that value under %ptr didn't change
+   %b = load i8, i8* %ptr, !invariant.group !1 ; Can't assume anything, because group changed
+  
----------------
You should insert a call between these two, since otherwise we can assume they load the same value because the value cannot have changed between the two loads.

================
Comment at: docs/LangRef.rst:4454
@@ +4453,3 @@
+   %newPtr2 = call i8* @llvm.invariant.group.barrier(i8* %ptr)
+   %d = load i8, i8* %newPtr2, !invariant.group !0  ; Can't step through invariant.group.barrier to get value of %ptr
+   
----------------
Again, insert a call before this load, since otherwise we can prove that this loads 42 because we just saw a store of 42 to the same region of memory.


http://reviews.llvm.org/D11399





More information about the llvm-commits mailing list