[LLVMdev] Intel Memory Protection Extensions (and types question)

Tue Sep 10 02:13:46 PDT 2013

On Tue, Sep 10, 2013 at 1:04 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> Hi Kevin,
>
> We're also interested in support for fat pointers in LLVM/clang and it
> would be nice to have some general infrastructure for them (we currently
> have a load of hacks).  There are a lot of research architectures with fat
> pointers, and MPX is likely to be just the first of many to start hitting
> real silicon soon.  There are a few properties that we'd ideally want to
> represent in the IR and back ends:
>
> - Pointers are now not solely integers, they contain other metadata
> - Fat and thin pointers may coexist in the same program and have different
> sizes
> - The in-memory size of a pointer is not always log2() of its addressable
> range
> - There are some registers that either only store pointers or only store
> pointer metadata
> - Loads and stores of pointers may need to be treated differently to loads
> and stores of data
>
> I believe that our case and MPX (which is quite close to HardBounds) are
> close to being opposite end of the spectrum, so it would be nice if we
> could come up with a generic design that can support both, as it would then
> simplify life for any future architectures that have this support.  In our
> case:
>
> - Fat pointers are 256 bits
> - The metadata is stored alongside the data
> - There are special registers and instructions for manipulating pointers.
>
> In the MPX case:
>
> - Fat pointers are 320 bits
>

How did you come with 320 bits?
320=64*4+64, which is the size of the metadata table entry plus pointer
size, but why do you call this a fat pointer?
In MPX, the fat pointer never exists as a single entity.

--kcc

> - The metadata is stored in separate tables
> - There are special instructions for loading metadata from the table into
> registers
> - There are special instructions for loading and storing metadata
> somewhere explicit
> - There are special load / store instructions for
>
> In the IR, we are representing fat pointers as pointers in another address
> space.  Most of the pointers-are-all-the-same-size assumptions in the IR
> are now fixed, however there are still some pointers-are-integers
> assumptions, for example GEPs suddenly find their indexes i256 bits, even
> though the range of the pointer is only 64 bits.  This can probably be
> solved by extending DataLayout to add some extra information about
> pointers, as was recently done with the work to allow them to be different
> sizes in different address spaces.
>
> In the back end, you need the register allocator to be able to handle the
> notion of paired registers.  This might be expressed by defining pairs of a
> GPR + a bounds register as a separate register set that aliases with the
> GPRs, but I don't think TableGen is quite expressive enough for that.
>
> We also need explicit support for inttoptr and ptrtoint in the back end,
> as moving between integer and address registers requires explicit
> conversion for us, and somewhat better matching for pointers in different
> address spaces in TableGen.
>
> David
>
> On 9 Sep 2013, at 21:03, "Schoedel, Kevin P" <kevin.p.schoedel at intel.com>
> wrote:
>
> > Hi all,
> >
> > I'm currently adding new instructions and registers to the X86 code
> > generator for Intel Memory Protection Extensions [1].
> >
> > A class of special-purpose registers BNDx each holds 2 x 64-bit values.
> > The components are not individually readable or writable (except by
> > going through memory) but there are instructions that read only one
> > of the two elements. The two 64-bit values can be considered opaque,
> > that is, not useful outside of the specific instructions using this
> > register class.
> >
> > After much experimentation, I think it's necessary to model this in
> > the backend with a new MVT code (ValueTypes.h). Trying to fake it
> > with an existing type (e.g. v2i64 or i128) leads to these registers
> > being misused for other values and vice versa.
> >
> > We want to have intrinsics map to some of these instructions (both
> > IR and C, in the usual <*intrin.h> form). I'm trying to avoid
> > having the added MVT escape the code generator by using some other
> > type representation in IR, but don't have that working yet.
> >
> > I've put a small patch on Phabricator, recognizing that this is not
> > committable until there are intrinsics or other means of testing.
> > http://llvm-reviews.chandlerc.com/D1630
> >
> > Comments welcomed.
> >
> > [1] Chapter 9, Intel Architecture Instruction Set Extensions
> > Programming Reference, July 2013,
> > http://download-software.intel.com/sites/default/files/319433-015.pdf
> >
> > --
> > Kevin Schoedel, Software Developer, Intel of Canada
> > <kevin.p.schoedel at intel.com>      +1 (519) 772-2580
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/279c6666/attachment.html>