Yichao Yu via llvm-dev
2017-Oct-30 01:01 UTC
[llvm-dev] Status of llvm.invariant.{start|end}
Hi,>From LangRef, these intrinsics seems really useful for letting LLVMknow 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
Anna Thomas via llvm-dev
2017-Oct-31 15:18 UTC
[llvm-dev] Status of llvm.invariant.{start|end}
Hi Yichao, 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. 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
Yichao Yu via llvm-dev
2017-Oct-31 16:17 UTC
[llvm-dev] Status of llvm.invariant.{start|end}
> 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 >