llvm dev - Sep 2013 - [LLVMdev] Intel Memory Protection Extensions (and types question)

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>

On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote:
> How did you come with 320 bits? 
> 320=64*4+64, which is the size of the metadata table entry plus pointer
size,
Sorry, that should have been 192.  The specification allows the metadata to be
stored either in look-aside tables or explicitly managed.  The tables impose a
very large storage space penalty, so are most likely to be used with C or
similar language where it is difficult to modify the data layout.  For languages
where there is no requirement to maintain an ABI that interoperates with non-MPX
code, the metadata can be stored inline when running in bounds-checked mode.  I
forgot that when using it in this mode you needed to store less metadata than
when using the bound tables.
> but why do you call this a fat pointer?
Because that's what it is: a pointer + metadata
> In MPX, the fat pointer never exists as a single entity. 
The pointer and metadata exist in separate registers, but single instructions
(loads and stores) operate on the pointer + metadata.

David

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at
cl.cam.ac.uk
> wrote:
> On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com>
wrote:
>
> > How did you come with 320 bits?
> > 320=64*4+64, which is the size of the metadata table entry plus
pointer
> size,
>

>
> Sorry, that should have been 192.  The specification allows the metadata
> to be stored either in look-aside tables or explicitly managed.

Is it? Which specification are you referring to?
http://download-software.intel.com/sites/default/files/319433-015.pdf (chapter
9) doesn't say anything like this. (Or does it?)

> The tables impose a very large storage space penalty, so are most likely
> to be used with C or similar language where it is difficult to modify the
> data layout.  For languages where there is no requirement to maintain an
> ABI that interoperates with non-MPX code, the metadata can be stored inline
> when running in bounds-checked mode.  I forgot that when using it in this
> mode you needed to store less metadata than when using the bound tables.
>
> > but why do you call this a fat pointer?
>
> Because that's what it is: a pointer + metadata
>
> > In MPX, the fat pointer never exists as a single entity.
>
> The pointer and metadata exist in separate registers, but single
> instructions (loads and stores) operate on the pointer + metadata.
>
Which MPX instructions do you mean here?

--kcc
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/87a5d38f/attachment.html>