Displaying 8 results from an estimated 8 matches for "inaccessiblemem_or_argmemon".
Did you mean:
inaccessiblemem_or_argmemonly
2016 Feb 10
3
RFC: Remove inaccessiblememonly from 3.8 branch
...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
attrib...
2020 Apr 30
3
Function attributes for memory side-effects
...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...
2019 Dec 16
7
[RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume
...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...
2020 Apr 28
2
Function attributes for memory side-effects
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
2017 Oct 30
2
Status of llvm.invariant.{start|end}
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
2019 Dec 18
2
[RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume
...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.
>
>
>...
2017 Oct 31
2
Status of llvm.invariant.{start|end}
...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 th...
2019 Dec 18
2
[RFC] How to manifest information in LLVM-IR, or, revisiting llvm.assume
...>>> 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 covere...