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

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>

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

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>