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

David Chisnall David.Chisnall at cl.cam.ac.uk
Tue Sep 10 02:47:49 PDT 2013


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





More information about the llvm-dev mailing list