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

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat May 13 18:44:33 PDT 2017


sanjoy added a subscriber: apilipenko.
sanjoy added a comment.

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

> @hfinkel Oh, my bad--I now remember that this came up long ago...


Firstly, going back one step to the `@llvm.safe.load.<ty>` intrinsic -- I think it would be fine to add a bit to `load` instructions that marks it as "safe" (i.e. it returns `undef` on being passed a non-dereferenceable pointer).  Metadata won't do here since stripping the hypothetical `!is_safe` metadata from a load instruction won't be behavior preserving.  This solves the issues you mentioned around integrating a new kind of load with the rest of LLVM, but you'll still have to implement safe loads, which can be tricky as you said.

> @sanjoy Can you confirm that a dereferenceable attribute on getelementptr would be an acceptable IR extension?

A GEP that always produces a dereferenceable value may be tricky to implement since we'll have to remember to strip said attribute whenever we hoist GEPs; and LLVM likes to hoist GEP's without thinking too much.  But I believe this is going in the right direction -- we should not have soundness problems as long as the safety of some operation is guaranteed by some //other// preceding operation.

JFYI, we solved this problem for Java by modeling the Java type system in LLVM IR.  We have a way of communicating Java type layouts (which contains dereferenceability and invariance information) from our JVM frontend to LLVM[0], and LLVM uses this functionality to compute type layouts for values whose types it can infer.  While we don't have any near term plans of upstreaming said infrastructure, if you wanted to take on the task of building something like this upstream, we may be able to use it.  +CC @apilipenko -- he gave a talk on this in EuroLLVM 2017.

[0]: LLVM upstream merged with some local non-upstreamed changes


Repository:
  rL LLVM

https://reviews.llvm.org/D18738





More information about the llvm-commits mailing list