<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">isTarget means that the intrinsics are generated in the ###GenIntrinsic.inc file instead of in the Intrinsics.gen file. Because I don't use the high level IntrinsicsPTX.td
file, I'm not sure how exactly to access it if the isTarget is specified there.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Justin Holewinski [mailto:justin.holewinski@gmail.com]
<br>
<b>Sent:</b> Thursday, December 08, 2011 10:43 AM<br>
<b>To:</b> Villmow, Micah<br>
<b>Cc:</b> Alberto Magni; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] PTX builtin functions.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <<a href="mailto:Micah.Villmow@amd.com">Micah.Villmow@amd.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">It is my understanding that all you need to do is specify let isTarget = 1 in your .td file and it will generate
target specific intrinsics. This should allow you to keep the IntrinsicsPTX.td file in the same location.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td? How do we then get at the generated files in the PTXIntrinsicInfo class in the back-end?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What exactly does isTarget do? It seems to remove a lot of the intrinsic information in the Intrinsics.gen file, but I can't find any documentation on it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Micah</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Justin Holewinski [mailto:<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>]
<br>
<b>Sent:</b> Monday, December 05, 2011 6:13 AM<br>
<b>To:</b> Alberto Magni<br>
<b>Cc:</b> Villmow, Micah; LLVM Developers Mailing List</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [LLVMdev] PTX builtin functions.<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <<a href="mailto:alberto.magni86@gmail.com" target="_blank">alberto.magni86@gmail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Justin,<br>
<br>
sorry for the delay, I have been busy.<br>
<br>
Micah's proposal requires to move the definitions of the intrinsics<br>
from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td<br>
thus allowing the generation of the file PTXGenIntrinsics.inc which<br>
will be included by PTXIntrinsicInfo.cpp.<br>
This is a quite big modification, do you agree with this ?<br>
Or do you have a better solution.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm opposed to this, mainly because we need the intrinsic definitions to be defined during LLVM IR optimization and not just at code-gen time. This is particularly important for
pure intrinsics, like llvm.ptx.read.tid.x(), where the optimizers can fold multiple calls to these functions into a single call. Without the intrinsic definitions in include/llvm/IntrinsicsPTX.td, this optimization would be illegal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">At the moment, I'm not seeing a clean solution to this. Overloading the intrinsics by writing custom code in PTXIntrinsicInfo.h/.cpp is only a partial solution, with the problems
mentioned above. In my mind, the cleanest solution would be to just write out explicit intrinsics for each possible type. We can still use multiclasses to an extent:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">multiclass PTXBinaryIntrinsic<string prefix> {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> def _u16 : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], [InstrNoMem]>,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> GCCBuiltin<!strconcat(prefix, "_u16")>;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> // Repeat for s16, u32, s32, u64, s64, f32, f64<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">defm int_ptx_mad<"__builtin_ptx_mad">;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It's not the cleanest, but it gets the job done (unless I'm missing something).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
Also I don't know yet how to make llvm recognize the intrinsics<br>
defined in lib/Target/PTX/PTXIntrinsics.td, the only other<br>
backend that does so is MBlaze.<br>
<br>
A tentative patch is attached.<br>
<br>
Bye,<br>
Alberto<br>
<br>
On Wed, Nov 23, 2011 at 2:36 PM, Justin Holewinski<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:<br>
><br>
> On Nov 23, 2011 8:33 AM, "Justin Holewinski" <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>> On Nov 23, 2011 6:57 AM, "Alberto Magni" <<a href="mailto:alberto.magni86@gmail.com" target="_blank">alberto.magni86@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> > On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <<a href="mailto:Micah.Villmow@amd.com" target="_blank">Micah.Villmow@amd.com</a>><br>
>> > wrote:<br>
>> > > Alberto,<br>
>> > > The AMDIL backend solves your problem with intrinsic overloading this<br>
>> > > way:<br>
>> > > def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat;<br>
>> > ><br>
>> > > Where TernaryIntFloat is defined as:<br>
>> > > class TernaryIntFloat :<br>
>> > > Intrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>,<br>
>> > > LLVMMatchType<0>, LLVMMatchType<0>], []>;<br>
>> > ><br>
>> > > This allows us to write a multi-def for int_AMDIL_mad like so:<br>
>> > > defm MAD : TernaryIntrinsicFloat<IL_OP_MAD, int_AMDIL_mad>;<br>
>> > ><br>
>> > > Where TernaryIntrinsicFloat is defined as:<br>
>> > > multiclass TernaryIntrinsicFloat<ILOpCode opcode, Intrinsic intr><br>
>> > > {<br>
>> > > def _f32 : ThreeInOneOut<opcode, (outs GPRF32:$dst),<br>
>> > > (ins GPRF32:$src, GPRF32:$src2, GPRF32:$src3),<br>
>> > > !strconcat(opcode.Text, " $dst, $src, $src2, $src3"),<br>
>> > > [(set GPRF32:$dst,<br>
>> > > (intr GPRF32:$src, GPRF32:$src2, GPRF32:$src3))]>;<br>
>> > > def _v2f32 : ThreeInOneOut<opcode, (outs GPRV2F32:$dst),<br>
>> > > (ins GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3),<br>
>> > > !strconcat(opcode.Text, " $dst, $src, $src2, $src3"),<br>
>> > > [(set GPRV2F32:$dst,<br>
>> > > (intr GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3))]>;<br>
>> > > ...<br>
>> > > }<br>
>> > ><br>
>> > > Now, this doesn't completely work, because LLVM does not allow<br>
>> > > overloading of intrinsics values, so there needs to be a little coding in<br>
>> > > *IntrinsicInfo class.<br>
>> > > AMD always encodes builtin names as __amdil_mad_f32,<br>
>> > > __amdil_mad_v2f32, __amdil_mad_v4f32, etc....<br>
>> > > So in the function "*IntrinsicInfo::lookup_name", when attempting to<br>
>> > > find out what intrinsic the function maps to, the AMDIL backend strips off<br>
>> > > the type, and then looks up for just '__amdil_mad'.<br>
>> > ><br>
>> > > This is how you can do intrinsic overloading in LLVM.<br>
>> > ><br>
>> > > Hope this helps,<br>
>> > > Micah<br>
>> ><br>
>> > Thank you Micah, it really does.<br>
>> ><br>
>> > At the moment the PTX backend does not have a PTXIntrinsicInfo class,<br>
>> > the only backend which does so is MBlaze.<br>
>> > If Justin agrees with the approach I will look on how to generate the<br>
>> > PTXGenIntrinsics.inc file (I am still learning TableGen)<br>
>> > required by PTXIntrinsicInfo and write the lookUp method.<br>
>><br>
>> Looks good to me. For OpenCL support in clang, we definitely need the<br>
>> built-in function support. And the total number of intrinsics like this<br>
>> should be relatively minimal.<br>
><br>
> One thing I forgot to mention: once these are implemented, it may be worth<br>
> implementing some instruction selection patterns to collapse icmp/fcmp and<br>
> select pairs into Max/min whenever it makes sense.<br>
><br>
>><br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > Alberto<br>
>> ><br>
>> > ><br>
>> > >> -----Original Message-----<br>
>> > >> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a><br>
>> > >> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]<br>
>> > >> On Behalf Of Alberto Magni<br>
>> > >> Sent: Tuesday, November 22, 2011 8:41 AM<br>
>> > >> To: Justin Holewinski<br>
>> > >> Cc: LLVM Developers Mailing List<br>
>> > >> Subject: Re: [LLVMdev] PTX builtin functions.<br>
>> > >><br>
>> > >> On Mon, Nov 21, 2011 at 5:31 PM, Justin Holewinski<br>
>> > >> <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:<br>
>> > >> > On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni<br>
>> > >> <<a href="mailto:alberto.magni86@gmail.com" target="_blank">alberto.magni86@gmail.com</a>><br>
>> > >> > wrote:<br>
>> > >> >><br>
>> > >> >> On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski<br>
>> > >> >> <<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>> wrote:<br>
>> > >> >> > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni<br>
>> > >> >> > <<a href="mailto:alberto.magni86@gmail.com" target="_blank">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<br>
>> > >> 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<br>
>> > >> >> > the<br>
>> > >> list<br>
>> > >> >> > for<br>
>> > >> >> > the benefit of others.<br>
>> > >> >><br>
>> > >> >> I always forget "Reply to All".<br>
>> > >> >><br>
>> > >> >> > We can probably factor out a generic description, or even just<br>
>> > >> >> > use<br>
>> > >> the<br>
>> > >> >> > PTX_INT3 multiclass directly. The PTXIntrinsicInstrInfo.td file<br>
>> > >> is<br>
>> > >> >> > included<br>
>> > >> >> > by PTXInstrInfo.td, so anything defined in PTXInstrInfo.td is<br>
>> > >> available<br>
>> > >> >> > in<br>
>> > >> >> > PTXIntrinsicInstrInfo.td.<br>
>> > >> >><br>
>> > >> >> I agree with you but my class PTX_INTRINSIC_INT3 works with an<br>
>> > >> 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>
>> > >> ><br>
>> > >> ><br>
>> > >> > Alright, I'm fine with that.<br>
>> > >> ><br>
>> > >> >><br>
>> > >> >><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<br>
>> > >> variants.<br>
>> > >> >> > The<br>
>> > >> >> > results of max/min operations can definitely be different<br>
>> > >> depending on<br>
>> > >> >> > whether the operands are signed or unsigned. Since this<br>
>> > >> information is<br>
>> > >> >> > not<br>
>> > >> >> > encoded in LLVM types, we may want to create two versions for<br>
>> > >> >> > each<br>
>> > >> >> > 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>
>> > >> >> Yes, this the only way.<br>
>> > >> ><br>
>> > >> ><br>
>> > >> > A couple more comments:<br>
>> > >> ><br>
>> > >> > Please make sure to set TargetPrefix="ptx" for the intrinsics<br>
>> > >> (probably best<br>
>> > >> > in the multiclass, see PTXReadSpecialRegisterIntrinsic_r32)]<br>
>> > >><br>
>> > >> Ok<br>
>> > >><br>
>> > >> > I'm not sure how to define a GCCBuiltin for an intrinsic that can<br>
>> > >> take<br>
>> > >> > multiple types, but it's probably worth looking into so we can<br>
>> > >> > expose<br>
>> > >> this<br>
>> > >> > intrinsic to Clang.<br>
>> > >><br>
>> > >> This could be an issue. I looked for something similar in other<br>
>> > >> backends<br>
>> > >> and I found no previous examples. It may be worth to ask on the ML<br>
>> > >> explicitly for this.<br>
>> > >> The only fallback that I see is to define explicitly every intrinsic<br>
>> > >> for every data type,<br>
>> > >> but this would prevent the usage of the multiclass for the definition<br>
>> > >> of the patterns.<br>
>> > >><br>
>> > >><br>
>> > >> Bye.<br>
>> > >><br>
>> > >> ><br>
>> > >> ><br>
>> > >> >><br>
>> > >> >><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">alberto.magni86@gmail.com</a>><br>
>> > >> >> >> >>> wrote:<br>
>> > >> >> >> >>>><br>
>> > >> >> >> >>>> Dear Justin,<br>
>> > >> >> >> >>>><br>
>> > >> >> >> >>>> I am trying to add the support for some OpenCL builtin<br>
>> > >> functions<br>
>> > >> >> >> >>>> to<br>
>> > >> >> >> >>>> the PTX backend.<br>
>> > >> >> >> >>>> The attached file represent the first stub of a patch for<br>
>> > >> 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<br>
>> > >> >> >> >>> built-<br>
>> > >> in<br>
>> > >> >> >> >>> functions<br>
>> > >> >> >> >>> do not belong in the PTX back-end. These will be<br>
>> > >> >> >> >>> implemented<br>
>> > >> in<br>
>> > >> >> >> >>> 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<br>
>> > >> will<br>
>> > >> >> >> >>> only<br>
>> > >> >> >> >>> implement PTX intrinsics, which may be used by the OpenCL<br>
>> > >> built-in<br>
>> > >> >> >> >>> functions<br>
>> > >> >> >> >>> in libclc. However, this particular function (max)<br>
>> > >> corresponds to<br>
>> > >> >> >> >>> a<br>
>> > >> >> >> >>> PTX<br>
>> > >> >> >> >>> instruction, so it makes sense to implement it as an<br>
>> > >> intrinsic in<br>
>> > >> >> >> >>> the<br>
>> > >> >> >> >>> back-end.<br>
>> > >> >> >> >>> Second, intrinsic functions require a bit more work.<br>
>> > >> >> >> >>> You're<br>
>> > >> off to<br>
>> > >> >> >> >>> a<br>
>> > >> >> >> >>> great start, but intrinsics are implemented a bit<br>
>> > >> differently. It<br>
>> > >> >> >> >>> looks<br>
>> > >> >> >> >>> like LLVM does not have a max intrinsic, so we'll need to<br>
>> > >> create<br>
>> > >> >> >> >>> one.<br>
>> > >> >> >> >>> Have<br>
>> > >> >> >> >>> a look at include/llvm/IntrinsicsPTX.td. This file defines<br>
>> > >> the<br>
>> > >> >> >> >>> PTX-specific<br>
>> > >> >> >> >>> intrinsics. You can add an intrinsic for max here, and<br>
>> > >> >> >> >>> then<br>
>> > >> >> >> >>> implement<br>
>> > >> >> >> >>> a<br>
>> > >> >> >> >>> pattern-match in the PTXInstrInfo.td file. There is no<br>
>> > >> >> >> >>> need<br>
>> > >> to<br>
>> > >> >> >> >>> create<br>
>> > >> >> >> >>> a new<br>
>> > >> >> >> >>> SDNode type for intrinsics, unless they require some<br>
>> > >> >> >> >>> special<br>
>> > >> >> >> >>> 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<br>
>> > >> goes in<br>
>> > >> >> >> >> PTXInstrinsicInstrInfo.td.<br>
>> > >> >> >> >><br>
>> > >> >> >> ><br>
>> > >> >> >> > Thank you for the pointers I will let you know when I have<br>
>> > >> >> >> > the<br>
>> > >> first<br>
>> > >> >> >> > patch.<br>
>> > >> >> >> ><br>
>> > >> >> >> >>><br>
>> > >> >> >> >>> When you define a new intrinsic, use the following template<br>
>> > >> as a<br>
>> > >> >> >> >>> name:<br>
>> > >> >> >> >>> int_ptx_max. This will define the LLVM intrinsic as<br>
>> > >> >> >> >>> @llvm.ptx.max().<br>
>> > >> >> >> >>> Please follow the same convention when naming the<br>
>> > >> __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<br>
>> > >> >> >> >>>> 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<br>
>> > >> functions<br>
>> > >> >> >> >>> have<br>
>> > >> >> >> >>> been implemented for a little while now, so I'm surprised<br>
>> > >> >> >> >>> to<br>
>> > >> see<br>
>> > >> >> >> >>> that<br>
>> > >> >> >> >>> error.<br>
>> > >> >> >> >>> Perhaps it's because the fmax function is not defined as<br>
>> > >> >> >> >>> ptx_device.<br>
>> > >> >> >> >>><br>
>> > >> >> >> ><br>
>> > >> >> >> > This is the testcase that I am using to verify I the max<br>
>> > >> builtin<br>
>> > >> >> >> > function I am impementing<br>
>> > >> >> >> > is actually recognised. I took inspiration from the llvm-<br>
>> > >> 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<br>
>> > >> 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<br>
>> > >> >> >> >>>> some<br>
>> > >> >> >> >>>> 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" target="_blank">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>
>> > >> ><br>
>> > >> ><br>
>> > >> ><br>
>> > >> ><br>
>> > >> > --<br>
>> > >> ><br>
>> > >> > Thanks,<br>
>> > >> ><br>
>> > >> > Justin Holewinski<br>
>> > >> ><br>
>> > >><br>
>> > >> _______________________________________________<br>
>> > >> LLVM Developers mailing list<br>
>> > >> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
>> > ><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">-- <o:p>
</o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Justin Holewinski<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Justin Holewinski<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>