[llvm-dev] Status of llvm.invariant.{start|end}

[Yichao Yu via llvm-dev]

> We at Azul have been using invariant.start for marking objects as immutable after a certain point.
> Also, upstream changes to teach relevant optimizations about invariant.start and end were added
> last year.
>
> With respect to store to load forwarding, this is handled in GVN. I think the test cases in test/Transforms/GVN/invariant.start.ll
> handle what you’re looking for.

Hmm, I'm pretty sure I checked that.
It seems that none of the test cases in there actually requires
invariant.start for store-to-load forwarding? (they need
`invariant.start|end` to not be marked as modifying the memory but
should all work without the intrinsics.) AFAICT the simple case in the
issue I linked still doesn't work

```
declare void @g(i8*)

declare {}* @llvm.invariant.start.p0i8(i64, i8* nocapture) #0

define i8 @f() {
  %a = alloca i8
  store i8 0, i8* %a
  %i = call {}* @llvm.invariant.start.p0i8(i64 1, i8* %a)
  call void @g(i8* %a)
  %r = load i8, i8* %a
  ret i8 %r
}

attributes #0 = { argmemonly nounwind }
```

A related note, can this be marked as inaccessiblemem_or_argmemonly
plus readonly on the argument? As far as not messing with the alias
analysis goes, this works very well without LLVM knowning anything
about such a function. Of course the store to load forwarding still
need to be handled separately but it seems that this can avoid some of
the special cases on this intrinsics.

>
>
> Hope this helps,
> Anna
>
>> On Oct 29, 2017, at 9:01 PM, Yichao Yu via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>
>> Hi,
>>
>> From LangRef, these intrinsics seems really useful for letting LLVM
>> know about certain higher level immutability guarantee, e.g. for
>> objects that are not allowed to be mutated after construction.
>> However, it doesn't seem to work[1] and a quick code search suggests
>> that there's not a single optimization pass that's currently using it
>> for store to load forwarding, only very few that use it to eliminate
>> stores. The issue linked is marked as resolved-later and mentioned
>> that it "probably have to be redesigned before they work out right".
>> What has to be redesigned to make it work and is there a better way
>> that works currently to mark an object as immutable after a certain
>> point/in certain region?
>>
>> Yichao Yu
>>
>> [1] https://bugs.llvm.org/show_bug.cgi?id=5441
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>