search for: inaccessiblememon

I had this on my TODO list for a while, but the recent introduction of inaccessiblememonly makes it suddenly more urgent, as there is a risk to waste effort in duplicated work and/or end up with suboptimal solutions. I collected 2 use cases for inaccessiblememonly : - Allocation like functions. - Runtime functions for managed languages, that touch state that the program itself can ne...

...it points to. As a result, it is assumed that the load line 11 may not be eliminated. > > Which seems actually correct in the general case. > > >> >> After a bit of thought, it is correct in the general case, but definitively something stricter is needed here. Looking at inaccessiblememonly I'm not sure this is what is needed. What if the memory allocator is defined is the current module ? > At the moment, inaccessiblememonly would require separate compilation of the allocation function. >> >> This leads me to conclude this is way more linked to the memory allo...

...ave a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64) local_unnamed_addr #0 ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare void @useClosure(i8*) local_unnamed_addr #1 ; Function Attrs: alwaysinline norecurse nounwind define void @main() #1 { entry: %closure.raw = tail...

...n any LLVM release, but 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 tha...

...e now, especially if you want to use @trap_on for safety checks. Without re-ordering restrictions, a failed @trap_on will end up looking a lot like UB (since, say, you could reorder a failing range check across a call to fflush); and so that would be bad. You'd still have to be careful around inaccessiblememonly and friends, though. -- Sanjoy

...itcast) and so %3 may have access to it and clobber it. Can you give a bit more context? I'm not sure which of the examples you're talking about. > > After a bit of thought, it is correct in the general case, but > definitively something stricter is needed here. Looking at > inaccessiblememonly I'm not sure this is what is needed. What if the > memory allocator is defined is the current module ? At the moment, inaccessiblememonly would require separate compilation of the allocation function. > > This leads me to conclude this is way more linked to the memory > allocat...

...check to make sure this is the one that MDA actually calls. > > I don't think this is the problem. When there is only 2 calls to allocmemory, loads are optimized away as expected. But it seems that the analysis is confused with 3+ calls. > Third, you might want to take a look the new inaccessiblememonly > attribute. Depending on how you're modelling your allocation, this might > help resolve the aliasing problem in different way. However, be aware that > this is *very* new. In particular, I triggered an optimizer bug by adding > the new attribute to your particular example. :(...

...In case of library functions we actually "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", basica...

> > I'm not sure why this is an issue. Yes, these two intrinsics depend > on the current rounding mode according to the C standard, and yes, > LLVM in default mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. Any other intrinsic, like `floor`,

Hi! I'm interested in what attributes in LLVM mean, specifically how to say that the result is always the same for the given input parameters. The main thing would be to merge two calls with the same parameters when the function is declared but not defined. (just like two stores). I'll call this property mergability. %1 := call @test(%0) %2 := call @test(%0) and the optimization would

...of a call rather that an instruction? That is some call may have rounding mode argument and another call of the same intrinsic may have not? It would the third way to express FP environment, together with the current per-intrinsic way and the rejected per-basic-block one. I wonder if we can model “inaccessibleMemOnly” or something like that using this way. The main justification of splitting an intrinsic to constrained and non-constrained variants is that one has side effect and the other does not. If we could deliberately assign this property to a particular call, we could eventually merge constrained and no...

...se intrinsics and provide the rounding mode and exception behavior arguments using an operand bundle. We do still need some way to handle the side effects. My suggestion here is to add some new attribute that means “no side effects” in the absence of the strictfp attribute and something similar to “inaccessibleMemOnly” in the presence of strictfp. We could make the new attribute less restrictive than inaccessibleMemOnly in that it only really needs to act as a barrier relative to other things that are accessing the fp environment. I believe Ulrich suggested this to me at the last LLVM Developer Meeting. -And...

...n? That is some call may have >> rounding mode argument and another call of the same intrinsic may have not? >> It would the third way to express FP environment, together with the current >> per-intrinsic way and the rejected per-basic-block one. I wonder if we can >> model “inaccessibleMemOnly” or something like that using this way. The main >> justification of splitting an intrinsic to constrained and non-constrained >> variants is that one has side effect and the other does not. If we could >> deliberately assign this property to a particular call, we could eventual...

...that would >> make it not only depend on the arguments, you cannot hoist a call to >> `pure_div` out of a conditional like `if (b != 0) r = pure_div(a, b);`. >> >> `readnone` does *not* allow accesses to memory that "cannot be seen by >> LLVM". We have `inaccessiblememonly` for that. >> >> Please follow up with questions :) >> >> ~ Johannes >> >> >>  > Thanks, László >>  > _______________________________________________ >>  > LLVM Developers mailing list >>  > llvm-dev at lists.llvm.o...

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 Andy, Responses inline: On Mon, Feb 22, 2016 at 10:08 AM, Andrew Trick <atrick at apple.com> wrote: >> By memory barrier, do you mean things like fences? > That’s right. Conservatively, I would not hoist at the LLVM level past > opaque non-readonly calls or fences. Just for curiosity: why do you care about memory fences specifically? > I've begun to think that

I'm trying to fix that bug: https://llvm.org/bugs/show_bug.cgi?id=20049 It turns out this is the kind of optimization that I really need, as when it isn't done, all kind of other optimizations opportunities down the road are not realized as they are not exposed. I have no idea where to start digging for this. I assume there is some kind of interaction between memory dependency and alias

Hi Sanjoy, Thanks for feedback! As for memory effects, currently I use " inaccessiblememonly " for it. It allows to prove that it doesn't alias with any other load/store in the function, but doesn't allow CSE to eliminate it. It is not actually super-cool, because there is no way that we can safely hoist it out of loop (and sometimes we want to, for example to make unswitchi...

...llvm.launder.invariant.group is not a pure function: it creates a fresh invariant group each time it's called. One may mentally model this as getting a fresh invariant group identifier somewhere from a 'magic' memory inaccessible to no-one else, so its llvm attributes include at least: inaccessiblememonly speculatable nounwind. Its results must alias its argument.- strip({strip,launder}(X)) = strip(X). This is because we do not care which particular invariant group metadata is stripped.- launder({strip,launder}(X)) may be replaced with launder(X) by the optimiser. Note that this not mean that laun...

...llvm.launder.invariant.group is not a pure function: it creates a fresh invariant group each time it's called. One may mentally model this as getting a fresh invariant group identifier somewhere from a 'magic' memory inaccessible to no-one else, so its llvm attributes include at least: inaccessiblememonly speculatable nounwind. Its results must alias its argument. > strip({strip,launder}(X)) = strip(X). This is because we do not care which particular invariant group metadata is stripped. > launder({strip,launder}(X)) may be replaced with launder(X) by the optimiser. Note that this not mean t...