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

[Schoedel, Kevin P]

Hi Nadav,

At Tuesday, September 10, 2013 12:40 AM, Nadav Rotem
[mailto:nrotem at apple.com] wrote:
> Can you explain what kind of abstraction/support do you plan to implement
> over the MP instructions ? I imagine that you plan to add a few intrinsics,
> right ? I imagine that you don't need the register allocator to allocate the
> BND registers or anything fancy like that.

We do need register allocation; the bounds registers are a set of 4,
and there is no user-level (C intrinsic) access to specific registers,
and certainly no desire to reinvent the wheel with some kind of
ad-hoc allocation.

At the low level, I envision core LLVM intrinsics something like this
(details TBD; attributes elided for simplicity):

    ; This type represents a pointer bounds pair. (We want to avoid
    ; allowing IR that lets the individuals bounds 'escape' without
    ; using an @llvm.mpx intrinsic.)
    llvm.x86.mpx.bounds = type opaque

    ; Build a set of bounds from a base address and size.
    declare %llvm.x86.mpx.bounds @llvm.x86.mpx.mk(i8* %p, i64 %size)

    ; Verify bounds. These take a plain pointer and return a
    ; (bitwise identical) pointer painted green.
    declare i8* @llvm.x86.mpx.cl(%llvm.x86.mpx.bounds, i8*)
    declare i8* @llvm.x86.mpx.cu(%llvm.x86.mpx.bounds, i8*)

    ; Store and loads bounds 'elsewhere'; these allow transferring
    ; bounds across ABI boundaries without affecting existing data
    ; layouts.
    declare void @llvm.x86.mpx.sx(%llvm.x86.mpx.bounds, i8*, i8**)
    declare %llvm.x86.mpx.bounds @llvm.x86.mpx.lx(i8**)

The above correspond closely to MPX instructions (and would also have
obvious non-MPX instruction sequences or software implementations,
should anyone want to apply the model elsewhere).

The normal MPX use case has the above intrinsics inserted at pointer
definitions and uses by an MPX analysis pass (completely optional, but
ideally drawing on existing work wherever practical). We'd expect
generic optimizations to eliminate redundant checks, and improve those
generic optimizations if necessary.

GCC and ICC have a set of C-level intrinsics, described in the GCC
notes[1], that operate on 'painted' pointers (using that terminology
to distinguish them from purely fat pointers, since MPX manages the
'fat' separately). These are intended primarily for use in low-level
memory management libraries, where the compiler can't determine itself
that a specific bounded memory region is being defined. We currently
envisage lowering these to the above LLVM intrinsics are the start of
the optional MPX pass.

[1] http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#Compiler_intrinsics_and_attributes

Regards,

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