<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=iso-8859-1">
<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;}
span.hoenzb
{mso-style-name:hoenzb;}
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"">James,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thanks for the suggestion for how to make this case easier to handle. I'll bring this up to the entire working group in our next meeting.
<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"">Micah<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""> mankeyrabbit@gmail.com [mailto:mankeyrabbit@gmail.com]
<b>On Behalf Of </b>James Molloy<br>
<b>Sent:</b> Friday, September 28, 2012 9:46 AM<br>
<b>To:</b> Villmow, Micah<br>
<b>Cc:</b> Carlos Sánchez de La Lama; Pekka Jääskeläinen; Ouriel, Boaz; pocl-devel@lists.sourceforge.net; cfe-dev@cs.uiuc.edu; llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional specification is now available in the Khronos website<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Micah,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is irrelevant for corner conditions) to get valid SPIR that it is *very* difficult to get into a shape that you can code
generate for CPUs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Even the SAFECode snippet that Pekka noted doesn't even handle the case of ConstantShuffleVectors, for example.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You can easily simplify this problem with a restriction in SPIR: disallow ConstantExpr casts - no ptrtoint constant expression. Because GlobalVariables have pointer type, if you disallow converting their type to non-pointer type in a constantexpr,
the number of constantexpr subclasses you have to deal with is drastically reduced (to essentially just BitCast and GEP).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That would be a simple, reasonable restriction that would stop potentially maliciously horrible test cases causing all CPU SPIR clients to write upwards of a hundred lines of conversion code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">James<o:p></o:p></p>
<div>
<p class="MsoNormal">On 28 September 2012 16:48, Villmow, Micah <<a href="mailto:Micah.Villmow@amd.com" target="_blank">Micah.Villmow@amd.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Carlos,<br>
AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires
extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being said, both ways of doing it are equally valid, but the choice of which way to do it is a implementation decision. I don't think
it would be that difficult to lower global variables to function arguments given SPIR representation.<br>
<span style="color:#888888"><br>
<span class="hoenzb">Micah</span></span><o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
> -----Original Message-----<br>
> From: Carlos Sánchez de La Lama [mailto:<a href="mailto:csanchezdll@gmail.com">csanchezdll@gmail.com</a>]<br>
> Sent: Friday, September 28, 2012 12:34 AM<br>
> To: James Molloy<br>
> Cc: Pekka Jääskeläinen; Ouriel, Boaz; <a href="mailto:pocl-devel@lists.sourceforge.net">
pocl-devel@lists.sourceforge.net</a>;<br>
> Villmow, Micah; <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>; <a href="mailto:llvmdev@cs.uiuc.edu">
llvmdev@cs.uiuc.edu</a><br>
> Subject: Re: [pocl-devel] [cfe-dev] [LLVMdev] SPIR provisional<br>
> specification is now available in the Khronos website<br>
><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> Hi guys,<br>
><br>
> > So it is valid SPIR, as the specification stands, to manipulate<br>
> > __local variables as Constants in a way that is extremely difficult to<br>
> > undo. That is, in order to transform SPIR to code that can run on a<br>
> > CPU, the GlobalVariable (which is a subclass of Constant) must be<br>
> > replaced with a dynamically calculated Value (which is not a subclass<br>
> of constant).<br>
><br>
> What about translating automatic locals to function scope pointers?<br>
> This will make handling of automatic locals and local pointer arguments<br>
> similar, which is desirable as they are just a way to describe the same<br>
> thing (I understand automatic locals as just a simpler way to use local<br>
> buffers than local arguments).<br>
><br>
> In fact, pocl converts automatic locals to implicit "extra" kernel<br>
> arguments and manages both cases the same way.<br>
><br>
> Carlos<br>
<br>
<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>