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

[Schoedel, Kevin P]

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