[PATCH] D18738: Add new !unconditionally_dereferenceable load instruction metadata

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 11 13:19:13 PDT 2017


hfinkel added a comment.

In https://reviews.llvm.org/D18738#752476, @whitequark wrote:

> @sanjoy
>
> > I'd be okay (even happy! :) ) if you add a @llvm.safe.load.<ty> intrinsic that never has UB, and returns undef if the address passed to it is not dereferenceable. That intrinsic could then be marked speculatable. If needed, we could even implement the intrinsic by trying to read from the address passed in, and by catching the SIGSEGV or SIGBUS, if any.
>
> First, it is not realistically possible to implement on most platforms (SEH *might* be fine but even then I'm not sure). Second, every pass that looks at loads will have to be amended in an invasive way (a quick look at LICM alone tells me this will be a nightmare as it passes bare LoadInst* everywhere...). Third, it would be crippled compared to real loads, as it won't support some attributes loads do (e.g. `!invariant.load`) and adding support for that will, AFAICT, require adding a new return value attribute, similar to how nonnull and dereferenceable are currently implemented there. Fourth, I don't think it will be easy to plug into the current AA architecture.
>
> Even if all the rest was fixed, the lack of `!invariant.load` alone makes it completely useless for our use case so I suggest not discussing this proposal further.
>
> Let's back away a bit. My current issue is that my frontend generates lots of deeply nested loads in inner loops. This happens because it is translating Python, and you can easily end up with something like:
>
>   for bs in as:
>     for b in bs:
>       c += self.core.dds0.ftw
>   
>
> The frontend guarantees that all these pointers are always dereferenceable. In fact every single SSA value of pointer type in the entire emitted IR is dereferenceable and nonnull. The frontend also knows that most of these loads are ultimately constant (in the case above, a simplified extract of real-world code, self.core.dds0 will never change for the entire program lifetime). The frontend is not able to hoist the loads into preheader itself because it does not perform inlining and so does not have enough visibility.
>
> How can I tell LLVM that these loads may be safely hoisted?


Would it make more sense to have a way to mark the pointer SSA value as being dereferenceable (instead of trying to make the access itself). This seems more in line with how we handle known-dereferenceable function arguments, and might be semantically cleaner.


Repository:
  rL LLVM

https://reviews.llvm.org/D18738





More information about the llvm-commits mailing list