search for: inaccessiblemem_or_argmemonly

...this is about to change in 3.8. Once that changes, we will have accepted a backwards compatibility guarantee with bitcode which is potentially concerning for a new attribute in such a half developed state. Given the preceding, I'd like to propose that we remove the inaccessiblememonly and inaccessiblemem_or_argmemonly attributes from the 3.8 release branch. This could be done by either a) actually removing the code, or b) simply disabling it. If we remove the documentation from the LangRef, disable the LL and bitcode parsing for the attribute, and explicitly document that we are not reserving the attribut...

...quot;know" the side effects and will add the appropriate attributes. As you said, fast math flags are needed for math library functions that may otherwise write errno. The full list of attributes we have so far is:    access locations: `readnone`, `inaccessiblememonly`, `argmemonly`, and `inaccessiblemem_or_argmemonly`  and access "kinds": `readonly` and `writeonly` Except for `readnone` you can combine a location attribute with a "kind" or have one of either alone. The Attributor does internally derive more "locations", basically any combination of:   local memory   constant me...

...ve anyway. - Reconstructing information from the pattern of instructions that feed into the `llvm.assume` is also not optimal, especially since we do not need to "optimize" these instructions anyway. - The current (=arbitrary) side-effects of `llvm.assume` are too strong. We have `inaccessiblemem_or_argmemonly` and we might be able to come up with something even more specialized for this, e.g., `control_dependences_only` to indicate that there are only control dependences. - Some Design Ideas: 1) Use named operand bundles to encode information. If we want to encode property XYZ for a value %...

Hi All I am writing a pass which requires checking dependences, and am having trouble dealing with function calls. Specifically, I want to be able to know when a called function does not have any side effects (e.g. math library functions like sqrt), and was wondering if there are attributes that specify this behavior (I know there is the ‘noread’ attribute but wasn’t sure if there’s something

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

...pattern of instructions that feed > > into the `llvm.assume` is also not optimal, especially since we do > > not need to "optimize" these instructions anyway. > > > > - The current (=arbitrary) side-effects of `llvm.assume` are too strong. > > We have `inaccessiblemem_or_argmemonly` and we might be able to come > > up with something even more specialized for this, e.g., > > `control_dependences_only` to indicate that there are only control > > dependences. > > This is all well put; I think you’ve covered the major weaknesses. > > > &g...

...variant.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...

...>>> into the `llvm.assume` is also not optimal, especially since we do > >>> not need to "optimize" these instructions anyway. > >>> > >>> - The current (=arbitrary) side-effects of `llvm.assume` are too strong. > >>> We have `inaccessiblemem_or_argmemonly` and we might be able to come > >>> up with something even more specialized for this, e.g., > >>> `control_dependences_only` to indicate that there are only control > >>> dependences. > >> > >> This is all well put; I think you’ve covered...