<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 1:04 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kevin,<br>
<br>
We're also interested in support for fat pointers in LLVM/clang and it would be nice to have some general infrastructure for them (we currently have a load of hacks). There are a lot of research architectures with fat pointers, and MPX is likely to be just the first of many to start hitting real silicon soon. There are a few properties that we'd ideally want to represent in the IR and back ends:<br>
<br>
- Pointers are now not solely integers, they contain other metadata<br>
- Fat and thin pointers may coexist in the same program and have different sizes<br>
- The in-memory size of a pointer is not always log2() of its addressable range<br>
- There are some registers that either only store pointers or only store pointer metadata<br>
- Loads and stores of pointers may need to be treated differently to loads and stores of data<br>
<br>
I believe that our case and MPX (which is quite close to HardBounds) are close to being opposite end of the spectrum, so it would be nice if we could come up with a generic design that can support both, as it would then simplify life for any future architectures that have this support. In our case:<br>
<br>
- Fat pointers are 256 bits<br>
- The metadata is stored alongside the data<br>
- There are special registers and instructions for manipulating pointers.<br>
<br>
In the MPX case:<br>
<br>
- Fat pointers are 320 bits<br></blockquote><div><br></div><div>How did you come with 320 bits? </div><div>320=64*4+64, which is the size of the metadata table entry plus pointer size, but why do you call this a fat pointer?</div>
<div>In MPX, the fat pointer never exists as a single entity. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The metadata is stored in separate tables<br>
- There are special instructions for loading metadata from the table into registers<br>
- There are special instructions for loading and storing metadata somewhere explicit<br>
- There are special load / store instructions for<br>
<br>
In the IR, we are representing fat pointers as pointers in another address space. Most of the pointers-are-all-the-same-size assumptions in the IR are now fixed, however there are still some pointers-are-integers assumptions, for example GEPs suddenly find their indexes i256 bits, even though the range of the pointer is only 64 bits. This can probably be solved by extending DataLayout to add some extra information about pointers, as was recently done with the work to allow them to be different sizes in different address spaces.<br>
<br>
In the back end, you need the register allocator to be able to handle the notion of paired registers. This might be expressed by defining pairs of a GPR + a bounds register as a separate register set that aliases with the GPRs, but I don't think TableGen is quite expressive enough for that.<br>
<br>
We also need explicit support for inttoptr and ptrtoint in the back end, as moving between integer and address registers requires explicit conversion for us, and somewhat better matching for pointers in different address spaces in TableGen.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 9 Sep 2013, at 21:03, "Schoedel, Kevin P" <<a href="mailto:kevin.p.schoedel@intel.com">kevin.p.schoedel@intel.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> I'm currently adding new instructions and registers to the X86 code<br>
> generator for Intel Memory Protection Extensions [1].<br>
><br>
> A class of special-purpose registers BNDx each holds 2 x 64-bit values.<br>
> The components are not individually readable or writable (except by<br>
> going through memory) but there are instructions that read only one<br>
> of the two elements. The two 64-bit values can be considered opaque,<br>
> that is, not useful outside of the specific instructions using this<br>
> register class.<br>
><br>
> After much experimentation, I think it's necessary to model this in<br>
> the backend with a new MVT code (ValueTypes.h). Trying to fake it<br>
> with an existing type (e.g. v2i64 or i128) leads to these registers<br>
> being misused for other values and vice versa.<br>
><br>
> We want to have intrinsics map to some of these instructions (both<br>
> IR and C, in the usual <*intrin.h> form). I'm trying to avoid<br>
> having the added MVT escape the code generator by using some other<br>
> type representation in IR, but don't have that working yet.<br>
><br>
> I've put a small patch on Phabricator, recognizing that this is not<br>
> committable until there are intrinsics or other means of testing.<br>
> <a href="http://llvm-reviews.chandlerc.com/D1630" target="_blank">http://llvm-reviews.chandlerc.com/D1630</a><br>
><br>
> Comments welcomed.<br>
><br>
> [1] Chapter 9, Intel Architecture Instruction Set Extensions<br>
> Programming Reference, July 2013,<br>
> <a href="http://download-software.intel.com/sites/default/files/319433-015.pdf" target="_blank">http://download-software.intel.com/sites/default/files/319433-015.pdf</a><br>
><br>
> --<br>
> Kevin Schoedel, Software Developer, Intel of Canada<br>
> <<a href="mailto:kevin.p.schoedel@intel.com">kevin.p.schoedel@intel.com</a>> <a href="tel:%2B1%20%28519%29%20772-2580" value="+15197722580">+1 (519) 772-2580</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>