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

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

Hi Kevin, 

Thanks for working on this.  We usually try really hard to avoid adding new
types such as x86mmx.  I don’t know the memory-protection instruction set at all
but I imagine that you are not expecting other LLVM optimizations to interact
with them right ? (it looks that way from this example[1]).  If you are not
accessing the individual components then you can use i128, or even <2 x
i64>.

Thanks,
Nadav

[1]
http://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain


On Sep 9, 2013, at 1:03 PM, 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

Hi,

On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at apple.com]
wrote:
> Thanks for working on this.  We usually try really hard to avoid adding new
> types such as x86mmx.  I don't know the memory-protection instruction
set at
> all but I imagine that you are not expecting other LLVM optimizations to
> interact with them right ? (it looks that way from this example[1]).  If
you
> are not accessing the individual components then you can use i128, or even
<2
> x i64>.
We have put some effort into trying to use i128 or v2i64, but it
seems that post instruction selection LLVM is incredibly keen on
putting values of those types in their 'correct' register class
(e.g. XMM) in preference to the BNDx bounds registers. I haven't
found any workaround for that, and adding an MVT code (where there
is already precedent for oddballs like x86mmx and ppc_f128) seems
to be low impact compared to any change to general register
handling.

As well, BNDx register contents do not really match the semantics
of i128 or v2i64 or unfortunately even <2 x i8*>, though the last
is an attractive candidate for an IR representation.

As I mentioned, we do intend to contain this to the backend, and not
introduce a corresponding type to the IR, by ad-hoc handling of the
specific associated intrinsics. I certainly understand that adding
an IR basic type is not something that would be done lightly, but
adding an MVT code amounts to a handful of case labels.

Over time we intend to write bounds checking instrumentation
interoperable with that in gcc and icc; the plan is for this to
be isolated to its own IR pass(es) so that there is no impact on
compilation not using it.

-- 
Kevin Schoedel, Software Developer, Intel of Canada
<kevin.p.schoedel at intel.com>      +1 (519) 772-2580

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
- 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

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>