<div class="gmail_quote">On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <span dir="ltr"><<a href="mailto:alberto.magni86@gmail.com">alberto.magni86@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski<br>
<<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:<br>
> On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni <<a href="mailto:alberto.magni86@gmail.com">alberto.magni86@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Justin,<br>
>><br>
>> attached you find the patch for the integer max instruction.<br>
>> The multiclass PTX_INTRINSIC_INT3 in file PTXIntrinsicInstrInfo.td<br>
>> is almost an exact copy of PTX_INT3 in PTXInstrInfo.td, maybe<br>
>> a modification of this class can be defined in a separate file.<br>
><br>
><br>
> I'm copying llvmdev. We should keep discussions like this on the list for<br>
> the benefit of others.<br>
<br>
</div>I always forget "Reply to All".<br>
<div class="im"><br>
> We can probably factor out a generic description, or even just use the<br>
> PTX_INT3 multiclass directly. The PTXIntrinsicInstrInfo.td file is included<br>
> by PTXInstrInfo.td, so anything defined in PTXInstrInfo.td is available in<br>
> PTXIntrinsicInstrInfo.td.<br>
<br>
</div>I agree with you but my class PTX_INTRINSIC_INT3 works with an Intrinsic<br>
and not with a SDNode, like PTX_INT3.<br>
PTX_INTRINSIC_INT3 also requires the presence of the type of<br>
the immediate in the pattern, e.g. (i32 imm:$b).<br></blockquote><div><br></div><div>Alright, I'm fine with that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
>><br>
>><br>
>> Do you agree with this approach ?<br>
>> Also, do you think that a class like PTX_INTRINSIC_INT3_SIGNED<br>
>> (a clone of PTX_INT3_SIGNED) is required ?<br>
><br>
><br>
> Yes, I believe we should split these into signed and unsigned variants. The<br>
> results of max/min operations can definitely be different depending on<br>
> whether the operands are signed or unsigned. Since this information is not<br>
> encoded in LLVM types, we may want to create two versions for each integer<br>
> type; something like:<br>
><br>
> i32 @llvm.ptx.max.signed.i32(i32, i32)<br>
> i32 @llvm.ptx.max.unsigned.i32(i32, i32)<br>
<br>
</div>Yes, this the only way.<br></blockquote><div><br></div><div>A couple more comments:</div><div><ol><li>Please make sure to set TargetPrefix="ptx" for the intrinsics (probably best in the multiclass, see PTXReadSpecialRegisterIntrinsic_r32)</li>
<li>I'm not sure how to define a GCCBuiltin for an intrinsic that can take multiple types, but it's probably worth looking into so we can expose this intrinsic to Clang.</li></ol></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5"><br>
><br>
> Otherwise, the patch looks good.<br>
><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Alberto<br>
>><br>
>> On Wed, Nov 16, 2011 at 5:44 PM, Alberto Magni<br>
>> <<a href="mailto:alberto.magni86@gmail.com">alberto.magni86@gmail.com</a>> wrote:<br>
>> > On Wed, Nov 16, 2011 at 2:17 PM, Justin Holewinski<br>
>> > <<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:<br>
>> >> On Wed, Nov 16, 2011 at 9:16 AM, Justin Holewinski<br>
>> >> <<a href="mailto:justin.holewinski@gmail.com">justin.holewinski@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> On Wed, Nov 16, 2011 at 8:05 AM, Alberto Magni<br>
>> >>> <<a href="mailto:alberto.magni86@gmail.com">alberto.magni86@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> Dear Justin,<br>
>> >>>><br>
>> >>>> I am trying to add the support for some OpenCL builtin functions to<br>
>> >>>> the PTX backend.<br>
>> >>>> The attached file represent the first stub of a patch for the fmax<br>
>> >>>> builtin function.<br>
>> >>><br>
>> >>> First off, thanks for helping to improve the PTX back-end!<br>
>> >>> There are really two main issues here. First, OpenCL built-in<br>
>> >>> functions<br>
>> >>> do not belong in the PTX back-end. These will be implemented in the<br>
>> >>> libclc<br>
>> >>> library (<a href="http://www.pcc.me.uk/~peter/libclc" target="_blank">http://www.pcc.me.uk/~peter/libclc</a>). The back-end will only<br>
>> >>> implement PTX intrinsics, which may be used by the OpenCL built-in<br>
>> >>> functions<br>
>> >>> in libclc. However, this particular function (max) corresponds to a<br>
>> >>> PTX<br>
>> >>> instruction, so it makes sense to implement it as an intrinsic in the<br>
>> >>> back-end.<br>
>> >>> Second, intrinsic functions require a bit more work. You're off to a<br>
>> >>> great start, but intrinsics are implemented a bit differently. It<br>
>> >>> looks<br>
>> >>> like LLVM does not have a max intrinsic, so we'll need to create one.<br>
>> >>> Have<br>
>> >>> a look at include/llvm/IntrinsicsPTX.td. This file defines the<br>
>> >>> PTX-specific<br>
>> >>> intrinsics. You can add an intrinsic for max here, and then implement<br>
>> >>> a<br>
>> >>> pattern-match in the PTXInstrInfo.td file. There is no need to create<br>
>> >>> a new<br>
>> >>> SDNode type for intrinsics, unless they require some special handling<br>
>> >>> in the<br>
>> >>> C++ code, which I do not see being the case here.<br>
>> >><br>
>> >> Sorry, there's a typo here. The intrinsic pattern matching goes in<br>
>> >> PTXInstrinsicInstrInfo.td.<br>
>> >><br>
>> ><br>
>> > Thank you for the pointers I will let you know when I have the first<br>
>> > patch.<br>
>> ><br>
>> >>><br>
>> >>> When you define a new intrinsic, use the following template as a name:<br>
>> >>> int_ptx_max. This will define the LLVM intrinsic as @llvm.ptx.max().<br>
>> >>> Please follow the same convention when naming the __builtin_*<br>
>> >>> function.<br>
>> >>><br>
>> >>>><br>
>> >>>> The test case I am trying is the following:<br>
>> >>>><br>
>> >>>> define ptx_device float @f(float %x, float %y) {<br>
>> >>>> entry:<br>
>> >>>> %z = call float @fmax(float %x, float %y)<br>
>> >>>> ret float %z<br>
>> >>>> }<br>
>> >>>><br>
>> >>>> declare float @fmax(float, float)<br>
>> >>>><br>
>> >>>> But at the moment llc crashes saying that "calls are not supported",<br>
>> >>>> this does not<br>
>> >>>> happens with llvm builtins like llvm.sqrt.f32<br>
>> >>><br>
>> >>> Which version of LLVM are you using? Calls to PTX device functions<br>
>> >>> have<br>
>> >>> been implemented for a little while now, so I'm surprised to see that<br>
>> >>> error.<br>
>> >>> Perhaps it's because the fmax function is not defined as ptx_device.<br>
>> >>><br>
>> ><br>
>> > This is the testcase that I am using to verify I the max builtin<br>
>> > function I am impementing<br>
>> > is actually recognised. I took inspiration from the llvm-intrinsic.ll<br>
>> > test case.<br>
>> > The command I am using to compile is:<br>
>> ><br>
>> > llc -march=ptx32 -mattr=+ptx22 fmax.ll<br>
>> ><br>
>> > The option -mattr does not seem to have any effect.<br>
>> > I tried also with the ptx_device qualifier with the same outcome.<br>
>> > I am using llvm from the svn repository.<br>
>> ><br>
>> > Bye,<br>
>> ><br>
>> > Alberto<br>
>> ><br>
>> >>>><br>
>> >>>> Can you please give me a hint on what I am missing, or some general<br>
>> >>>> advice on how<br>
>> >>>> to add builtin functions.<br>
>> >>>><br>
>> >>>> Thank you in advance,<br>
>> >>>><br>
>> >>>> Alberto.<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>
>> >>> Justin Holewinski<br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >><br>
>> >> Thanks,<br>
>> >> Justin Holewinski<br>
>> >><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Thanks,<br>
><br>
> Justin Holewinski<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>