[llvm] [llvm] Support invariant.load on readonly intrinsics (PR #205916)
Nikita Popov via llvm-commits
llvm-commits at lists.llvm.org
Sat Jun 27 03:10:07 PDT 2026
nikic wrote:
> I am not sure if we should treat it as a global side effect (i.e., add a shadow state tracking which byte is immutable) or use the "access through the pointer" semantics like initializes. The former one is simple, but the state can be erased by llvm.invariant.end like https://godbolt.org/z/9YYhrzh9q.
I'm not really sure I understand what the second semantics that you have in mind here are. I do agree that it can't be possible for invariant.end to remove invariance started by `!invariant.load`. Current optimizations depend on `!invariant.load` not requiring you to prove that there is no `invariant.end` in between.
We can further generalize this to the case of nested invariant.start/end, where for something like this:
```
%p0 = call ptr @llvm.invariant.start.p0(i64 1, ptr %p)
%p1 = call ptr @llvm.invariant.start.p0(i64 1, ptr %p)
call void @llvm.invariant.end.p0(ptr %p1, i64 1, ptr %p)
```
The call to `invariant.end` on `%p1` cannot remove the invariance established by the first call. This is also something current optimizations depend on.
So I think the consequence of this is that we have a global invariance property that is associated with memory (rather than provenance), but it's not a single one. Closing one invariance scope does not mean that other open invariance scopes or `!invariant.load` no longer applies.
An alternative would be to just get rid of `invariant.end` entirely. We only ever optimize cases where there is no `invariant.end`, so it might make sense to just get rid of the concept.
Though in either case, we can consider `!invariant.load` to be a compact encoding for `invariant.start` on the loaded memory (without the possibility of a corresponding `invariant.end` call).
We also have `!invariant.group`, but I believe that one is entirely orthogonal to invariant.load/invariant.start because it is bound to the provenance of the pointer, rather than being a global property (sketched out in https://github.com/llvm/llvm-project/pull/200552#pullrequestreview-4449660820).
https://github.com/llvm/llvm-project/pull/205916
More information about the llvm-commits
mailing list