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

[Nadav Rotem]

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