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

[Kostya Serebryany]

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

> On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote:
>
> >
> >
> >
> > 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?)
>
> See the BNDMOV instruction, which allows the bounds to be explicitly
> loaded and stored to bounds registers.  Contrast with BNDLDX / BNDSTX,
> where the location is implicit.  The BNDMOV instruction is also used for
> stack spills of the bounds registers.  This allows MPX to be used for range
> checking in a similar way to the Thumb-2EE extensions.
>

Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is
not the real intention of the MPX developers
since a fat pointer will break all ABIs, and MPX tries to preserve them.
I don't think we need fat pointers to support MPX in LLVM -- it will
complicate the implementation beyond necessity. (My 2c)
All we need is to represent a 128-bit type that will live in BNDx registers.

--kcc


>
> >>  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?
>
> Ah, sorry, I was confusing MPX with one of the other HardBound-like
> schemes here.  In MPX, you must implicitly insert the BNDCU and BNDCL
> instructions.  I would expect that you'd want to model the BNDCU + BNDCL +
> MOV sequence as a single pseudo for as long as possible to ensure that the
> bounds checks were performed at the correct time and not elided, but they
> are separate instructions (although if they don't do micro-op fusion on the
> sequence I'd be shocked, since you can trivially do both bounds checks in a
> single cycle and speculatively enqueue the memory operation with enough
> time to cancel it if it turned out that the bounds checks should trap).
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130910/aaae51ca/attachment.html>