[LLVMdev] Intel Memory Protection Extensions (and types question)
kcc at google.com
Tue Sep 10 04:13:10 PDT 2013
On Tue, Sep 10, 2013 at 1:47 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> 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.
> >> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev