<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:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (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:0cm;
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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="RU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Actually OpenCL specification has the following text in “Built-in Functions” chapter (OpenCL
C 2.0 rev. 33):<o:p></o:p></span></a></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">“ User defined OpenCL C functions, behave per C standard rules for functions (C99, TC2, Section<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">6.9.1). On entry to the function, the size of each variably modified parameter is evaluated and<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;background:yellow;mso-highlight:yellow;mso-fareast-language:EN-US">the value of each argument expression is converted to the type of the corresponding
parameter as<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;background:yellow;mso-highlight:yellow;mso-fareast-language:EN-US">per usual arithmetic conversion rules described in section 6.2.6.</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">
Built-in functions described in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">this section behave similarly, except that in order to avoid ambiguity between multiple forms of<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">the same built-in function, implicit scalar widening shall not occur. Note that some built-in<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">functions described in this section do have forms that operate on mixed scalar and vector types,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">however.”
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">If I understand it correctly this text can help to resolve the overloading, since “usual arithmetic conversion rules”
from section 6.2.6 rank floating point and integer data types including vector flavors. On the other hand I don’t think it’s good idea to adopt this rule, since it doesn’t follow C++ overloading rules and definitely will deviate OpenCL behavior from C or C++.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Alexey<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Anastasia Stulova [mailto:Anastasia.Stulova@arm.com]
<br>
<b>Sent:</b> Monday, December 5, 2016 9:21 PM<br>
<b>To:</b> Richard Smith <richard@metafoo.co.uk>; Bruno Cardoso Lopes via Phabricator <reviews@reviews.llvm.org>; reviews+D27334+public+f2c5a66032c4c02e@reviews.llvm.org<br>
<b>Cc:</b> Bader, Alexey <alexey.bader@intel.com>; egor.churaev@gmail.com; yaxun.liu@amd.com; cfe-commits@lists.llvm.org; nd <nd@arm.com><br>
<b>Subject:</b> RE: [PATCH] D27334: [OpenCL] Ambiguous function call.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">>
</span><span lang="EN-GB">Perhaps that is the problem (that there are two modes that do different things)? Could we make the double overload be present but unselectable to diagnose this problem in that mode too?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If we could resolve the overload candidate to prefer ‘int -> float’ than ‘int->double’, it would work best.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">
<a href="mailto:metafoo@gmail.com">metafoo@gmail.com</a> [<a href="mailto:metafoo@gmail.com">mailto:metafoo@gmail.com</a>]
<b>On Behalf Of </b>Richard Smith<br>
<b>Sent:</b> 05 December 2016 17:53<br>
<b>To:</b> Bruno Cardoso Lopes via Phabricator; <a href="mailto:reviews+D27334+public+f2c5a66032c4c02e@reviews.llvm.org">
reviews+D27334+public+f2c5a66032c4c02e@reviews.llvm.org</a><br>
<b>Cc:</b> <a href="mailto:alexey.bader@intel.com">alexey.bader@intel.com</a>; <a href="mailto:egor.churaev@gmail.com">
egor.churaev@gmail.com</a>; <a href="mailto:yaxun.liu@amd.com">yaxun.liu@amd.com</a>; Anastasia Stulova;
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<b>Subject:</b> Re: [PATCH] D27334: [OpenCL] Ambiguous function call.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB">On 5 Dec 2016 9:42 am, "Anastasia Stulova via Phabricator via cfe-commits" <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Anastasia added a comment.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><br>
In <a href="https://reviews.llvm.org/D27334#612858" target="_blank">https://reviews.llvm.org/D27334#612858</a>, @bader wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D27334#611703" target="_blank">https://reviews.llvm.org/D27334#611703</a>, @Anastasia wrote:<br>
><br>
> > This change seems to modify normal C behavior again. Is there any strong motivation for doing this and if yes could it be done generically with C?<br>
><br>
><br>
> Motivation:<br>
><br>
> // Non-portable OpenCL 1.2 code<br>
> __kernel void foo(global float* out) {<br>
> out[get_global_id(0)] = sin(get_global_id(0));<br>
> }<br>
><br>
><br>
> This program compiles fine on OpenCL platform w/o doubles support<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Perhaps that is the problem (that there are two modes that do different things)? Could we make the double overload be present but unselectable to diagnose this problem in that mode too?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-GB">and fails otherwise.<br>
> If OpenCL driver supports doubles it provides at least two versions of 'sin' built-in math function and compiler will not be able to choose the right one for 'size_t' argument.<o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Do you have a real example? If someone passes an integer to 'sin', I think there's a better warning we can give them :)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB">> The goal of this warning is to let OpenCL developer know about potential issues with code portability.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB">I would argue this improves the portability much as it can also be misleading in some situations (because it refers to a potentially hypothetical problem). For example there can be builtin functions that only have a float
parameter (without a double version of it). This is for example the case with read_image functions that take a float coordinate value between 0 and 1. Unfortunately this warning won't be triggered on read_image functions because there is an overload candidate
with an int type of the same parameter too. But we can't exclude this situations to appear in the future or from some vendor extensions or even custom OpenCL code.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><br>
<br>
<a href="https://reviews.llvm.org/D27334" target="_blank">https://reviews.llvm.org/D27334</a><br>
<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
<p><br>--------------------------------------------------------------------<br>Joint Stock Company Intel A/O<br>Registered legal address: Krylatsky Hills Business Park, <br>17 Krylatskaya Str., Bldg 4, Moscow 121614, <br>Russian Federation</p><p>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.</p>
</body>
</html>