<div dir="ltr">It's been on the back-burner for awhile.  I'll clean it up and post it for review soon.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 7:48 PM, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote:<br>
> On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <<a href="mailto:tom@stellard.net">tom@stellard.net</a>> wrote:<br>
><br>
> > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote:<br>
> > > Good to know, thanks!<br>
> > ><br>
> > > Currently I'm just not declaring an i8 register class since we only have<br>
> > > load/store/convert available for that type.  This works fine for most<br>
> > uses,<br>
> > > but becomes a hassle when dealing with function parameters.  For example,<br>
> > > if the function argument is i8, the code in LowerFormalArguments sees it<br>
> > as<br>
> > > an i16 since that is the next target legal type.  For my target, we need<br>
> > to<br>
> > > load function parameters from a special memory pool; so I need to emit<br>
> > > any-extend loads of an 8-bit memory VT to a 16-bit register VT.  But I<br>
> > > don't see any way to get at the information that the function argument is<br>
> > > really 8 bits unless I go back to the llvm::Function definition.  This is<br>
> > > do-able, but feels wrong to be doing in TargetLowering.  I was trying to<br>
> > > get around this by declaring i8 as a legal type (strictly speaking, it<br>
> > *is*<br>
> > > legal in the target), and relying on the legalizer to perform any<br>
> > > extensions for me; but now it looks like it may be easier to just teach<br>
> > > SelectionDAGBuilder to pass along the original parameter type in<br>
> > > LowerFormalArguments and friends.<br>
> > ><br>
> ><br>
> > R600 has the same issue and we just use the llvm::Function definition to<br>
> > determine the type.  The only other alternative is to make i8 a legal<br>
> > type, loop through all ISD opcodes and set them all to promote<br>
> > for i8, and then fix whatever bugs you find in the SelectionDAG.<br>
> ><br>
><br>
> We're using the same approach of inspecting the Function definition, but<br>
> I'm trying to find a way to avoid that.  I've been trying the approach of<br>
> declaring an i8 register class and promoting the ops, but as Jim points<br>
> out, this currently doesn't work in SelectionDAG.  All I really need is a<br>
> way to determine if the original type is i8, so I'm trying to thread this<br>
> through ISD::InputArg.  Doesn't seem to be too invasive, I'm putting<br>
> together a patch now.<br>
><br>
<br>
</div></div>Hi Justin,<br>
<br>
Were you able to finish writing this patch?  I'm working on this problem<br>
now, and I am curious what your solution is.<br>
<br>
Thanks,<br>
Tom<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> ><br>
> > It would be really nice if it were possible to mark a type as load/store<br>
> > only, but I'm not sure how to begin implementing that.<br>
> ><br>
> > -Tom<br>
> > ><br>
> > > On Thu, Aug 8, 2013 at 1:37 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:<br>
> > ><br>
> > > > Hi Justin,<br>
> > > ><br>
> > > > This is a big weakness of the current SelectionDAG infrastructure.<br>
> > There's<br>
> > > > not a really clean way to do this. The legalizer assumes that if a<br>
> > type is<br>
> > > > "legal" at all, the target can do at least basic arithmetic on that<br>
> > type.<br>
> > > ><br>
> > > > Theoretically, your approach of setting the operations to<br>
> > > > "TargetLowering::Promote" for i8 should work. I think it would be<br>
> > > > reasonable to fix SelectionDAG to allow that. It's probably a<br>
> > non-trivial<br>
> > > > task, though.<br>
> > > ><br>
> > > > -Jim<br>
> > > ><br>
> > > > On Aug 8, 2013, at 7:35 AM, Justin Holewinski <<br>
> > <a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>><br>
> > > > wrote:<br>
> > > ><br>
> > > > > Is there a way to define a register class that is storage-only?  I<br>
> > want<br>
> > > > to have an i8 register class that I can use for loads/stores/converts,<br>
> > but<br>
> > > > that does not support arithmetic.<br>
> > > > ><br>
> > > > > It seems addOperationAction(ISD::ADD, MVT::i8, Promote) and<br>
> > > > SetPromotedToType(ISD::ADD, MVT::i8, MVT::i16) are not sufficient, as<br>
> > the<br>
> > > > legalizer just looks at whether or not the underlying type is legal<br>
> > (which<br>
> > > > it is).  So come instruction selection time I still have i8 adds.  Do I<br>
> > > > need to custom handle all 8-bit arithmetic, or is there some way to<br>
> > have<br>
> > > > the legalizer do the promotion like it would for an illegal type?<br>
> > > > ><br>
> > > > ><br>
> > > > > --<br>
> > > > ><br>
> > > > > Thanks,<br>
> > > > ><br>
> > > > > Justin Holewinski<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>
> > ><br>
> > > Thanks,<br>
> > ><br>
> > > Justin Holewinski<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>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Justin Holewinski<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>