Displaying 3 results from an estimated 3 matches for "rl256728".
2016 Feb 22
2
RFC: Add guard intrinsics to LLVM
...e the effect of
> "aliases-with-nothing-in-llvm" it's cleaner to use alias analysis.
(I've put this on the bug as well:)
https://llvm.org/bugs/show_bug.cgi?id=18912#c3
```
(In reply to comment #2)
> The test case in this bug report is fixed by
> http://reviews.llvm.org/rL256728.
>
> I'm closing this because I don't have a test case and I no longer think it
> makes much sense to mark may-unwind calls "readonly". An unwind path always
> touches some memory. That fact that it doesn't alias with LLVM-visible
I'm not sure about this -- wh...
2016 Feb 21
2
RFC: Add guard intrinsics to LLVM
...aythrow" calls (those without "nounwind) as having side effects? I
> vaguely remember some work being done to improve the situation, but
> last I checked LICM was still violating it, and who knows what else?
The specific case in the bug was fixed by David in
http://reviews.llvm.org/rL256728. But I agree with your concern, that
this notion of "readnone calls are always okay to remove" may have
leaked into other parts of LLVM.
> BTW, if you do want readonly semantics, why would you want readonly
> to be implicit instead of explicit?
I don't understand the question...
2016 Feb 17
7
RFC: Add guard intrinsics to LLVM
This is a proposal to add guard intrinsics to LLVM.
Couple of glossary items: when I say "interpreter" I mean "the most
conservative tier in the compilation stack" which can be an actual
interpreter, a "splat compiler" or even a regular JIT that doesn't
make optimistic assumptions. By "bailing out to the interpreter" I
mean "side exit" as