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

Hi,

On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at apple.com]
wrote:
> Thanks for working on this.  We usually try really hard to avoid adding new
> types such as x86mmx.  I don't know the memory-protection instruction
set at
> all but I imagine that you are not expecting other LLVM optimizations to
> interact with them right ? (it looks that way from this example[1]).  If
you
> are not accessing the individual components then you can use i128, or even
<2
> x i64>.
We have put some effort into trying to use i128 or v2i64, but it
seems that post instruction selection LLVM is incredibly keen on
putting values of those types in their 'correct' register class
(e.g. XMM) in preference to the BNDx bounds registers. I haven't
found any workaround for that, and adding an MVT code (where there
is already precedent for oddballs like x86mmx and ppc_f128) seems
to be low impact compared to any change to general register
handling.

As well, BNDx register contents do not really match the semantics
of i128 or v2i64 or unfortunately even <2 x i8*>, though the last
is an attractive candidate for an IR representation.

As I mentioned, we do intend to contain this to the backend, and not
introduce a corresponding type to the IR, by ad-hoc handling of the
specific associated intrinsics. I certainly understand that adding
an IR basic type is not something that would be done lightly, but
adding an MVT code amounts to a handful of case labels.

Over time we intend to write bounds checking instrumentation
interoperable with that in gcc and icc; the plan is for this to
be isolated to its own IR pass(es) so that there is no impact on
compilation not using it.

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

Hi Kevin, 

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. In that case the registers can be an immediate in
the intrinsic.  Maybe you can start by presenting the kind of intrinsics that
you want to implement.

Thanks,
Nadav 

On Sep 9, 2013, at 2:00 PM, Schoedel, Kevin P <kevin.p.schoedel at
intel.com> wrote:
> Hi,
> 
> On Monday, September 09, 2013 4:20 PM, Nadav Rotem [mailto:nrotem at
apple.com] wrote:
>> Thanks for working on this.  We usually try really hard to avoid adding
new
>> types such as x86mmx.  I don't know the memory-protection
instruction set at
>> all but I imagine that you are not expecting other LLVM optimizations
to
>> interact with them right ? (it looks that way from this example[1]). 
If you
>> are not accessing the individual components then you can use i128, or
even <2
>> x i64>.
> 
> We have put some effort into trying to use i128 or v2i64, but it
> seems that post instruction selection LLVM is incredibly keen on
> putting values of those types in their 'correct' register class
> (e.g. XMM) in preference to the BNDx bounds registers. I haven't
> found any workaround for that, and adding an MVT code (where there
> is already precedent for oddballs like x86mmx and ppc_f128) seems
> to be low impact compared to any change to general register
> handling.
> 
> As well, BNDx register contents do not really match the semantics
> of i128 or v2i64 or unfortunately even <2 x i8*>, though the last
> is an attractive candidate for an IR representation.
> 
> As I mentioned, we do intend to contain this to the backend, and not
> introduce a corresponding type to the IR, by ad-hoc handling of the
> specific associated intrinsics. I certainly understand that adding
> an IR basic type is not something that would be done lightly, but
> adding an MVT code amounts to a handful of case labels.
> 
> Over time we intend to write bounds checking instrumentation
> interoperable with that in gcc and icc; the plan is for this to
> be isolated to its own IR pass(es) so that there is no impact on
> compilation not using it.
> 
> -- 
> Kevin Schoedel, Software Developer, Intel of Canada
> <kevin.p.schoedel at intel.com>      +1 (519) 772-2580
> 
> 
>

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