<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/23 David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off. </blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.<br></blockquote><div><br></div><div style>
In our processor, addresses (i.e. pointers) must be assigned to a specific kind of registers before it can be used for memory access, which is the common part between yours and ours.</div><div style><br></div><div style>Here are 2 possible solutions for our problem:</div>
<div style>1. constrain instruction selection.</div><div style>1.1  use    "addRegisterClass(MVT::iPTR,  XXX::PTRRegClass);" to bind pointers and their register class.</div><div style>1.2  add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and insert reg-reg move operations if necessary. For example, (load reg,  addr:i32) means we read at 'addr' to fill 'reg'. Here, we modify it to (load reg,  addr:iPTR).</div>
<div style>1.3  in XXXInstrInfo.td, we give (load  reg,   iPTR:$addr) to match pattern.</div><div style>1.4  and finally we "hope" default register allocator do the proper thing.</div><div style><br></div><div style>
2. add an annotation pass before register allocation.</div><div style>2.1  we treat both integer and pointer as i32, and hence there is just "addRegisterClass(MVT::i32,  XXX::I32RegClass);"</div><div style>2.2  before register allocation we annote operands if they must reside in address register.</div>
<div style>2.3  register allocation assigns register class according to annotations mentioned in 2.2, and perhaps a custom register allocator has to be implemented.</div><div style><br></div><div style>Which way do you think is more feasible?</div>
<div style><br></div><div style>Regards.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span class=""><font color="#888888"><br>
David<br>
</font></span><div class=""><div class="h5"><br>
On 23 Jun 2013, at 15:49, 杨勇勇 <<a href="mailto:triple.yang@gmail.com">triple.yang@gmail.com</a>> wrote:<br>
<br>
> David, thanks for your immediate response.<br>
><br>
> Since iPTR is a reserved type for tablegen internal use, can you make a further explanation?<br>
><br>
> On the other hand, it can be simply treated as a register class assignment problem during register allocation.<br>
> Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from target constraint information about which register class is valid for a operand, and this is determined by which instruction consumes the operand.<br>

><br>
> So is there a convienient way to constrain register class assignment, like a tablegen interface or something else?<br>
><br>
> Regards.<br>
><br>
> 2013/6/21 David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>><br>
> We also have this problem, and have added iPTR types to the back end.  Our pointers are actually fat pointers, so this also requires tweaking some optimisations (for example, things like to turn GEPs with 64-bit offsets into pointer-sized offsets, but our pointers are larger than any integer type that we support...).  Most of the changes are a bit ugly, and I'm loath to upstream them without an in-tree target that has these requirements, or they will be hard for anyone else to keep working.<br>

><br>
> David<br>
><br>
> On 21 Jun 2013, at 06:00, 杨勇勇 <<a href="mailto:triple.yang@gmail.com">triple.yang@gmail.com</a>> wrote:<br>
><br>
> > llvm code generator lowers both integer and pointer types into ixx(say, i16, i32, i64, ...). This make senses for some optimizations.<br>
> ><br>
> > However, integer registers and pointer registers is expilicitly distinguished from each other for some architectures, like TriCore, Blackfin, and our lab prototype dsp, which accelerates address computation and memory access.<br>

> ><br>
> > I have already read this mail thread: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022142.html</a> , and I am wondering how is the progress about it.<br>

> ><br>
> > Thanks.<br>
> ><br>
> > --<br>
> > 杨勇勇 (Yang Yong-Yong)<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>
><br>
> --<br>
> 杨勇勇 (Yang Yong-Yong)<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>杨勇勇 (Yang Yong-Yong)
</div></div>