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

Nadav Rotem nrotem at apple.com
Mon Sep 9 13:19:44 PDT 2013

Hi Kevin, 

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


[1] http://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain

On Sep 9, 2013, at 1:03 PM, Schoedel, Kevin P <kevin.p.schoedel at intel.com> wrote:

> Hi all,
> I'm currently adding new instructions and registers to the X86 code
> generator for Intel Memory Protection Extensions [1].
> A class of special-purpose registers BNDx each holds 2 x 64-bit values.
> The components are not individually readable or writable (except by
> going through memory) but there are instructions that read only one
> of the two elements. The two 64-bit values can be considered opaque,
> that is, not useful outside of the specific instructions using this
> register class.
> After much experimentation, I think it's necessary to model this in
> the backend with a new MVT code (ValueTypes.h). Trying to fake it
> with an existing type (e.g. v2i64 or i128) leads to these registers
> being misused for other values and vice versa.
> We want to have intrinsics map to some of these instructions (both
> IR and C, in the usual <*intrin.h> form). I'm trying to avoid
> having the added MVT escape the code generator by using some other
> type representation in IR, but don't have that working yet.
> I've put a small patch on Phabricator, recognizing that this is not
> committable until there are intrinsics or other means of testing.
> http://llvm-reviews.chandlerc.com/D1630
> Comments welcomed.
> [1] Chapter 9, Intel Architecture Instruction Set Extensions
> Programming Reference, July 2013,
> http://download-software.intel.com/sites/default/files/319433-015.pdf
> -- 
> Kevin Schoedel, Software Developer, Intel of Canada
> <kevin.p.schoedel at intel.com>      +1 (519) 772-2580
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list