<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1038.35">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px}
</style>
<p class="p1">Some observations about storing the kernel information in metadata:</p><p class="p1"><br></p><p class="p1">In our CL implementation at Ziilabs we represented all the kernel attributes as separate NamedMDNodes. The kernel name is concatenated with a set of known postfixes. For example 'kernel foo(…)' produces nodes with names 'foo_is_kernel', 'foo_work_group_size_hint', 'foo_vec_type_hint' etc. The MDNodes carry Values appropriate to the attribute type (e.g. 3 integers for the work_group_size_hint).</p>
<p class="p2"><br></p>
<p class="p1">At any point passes (including machine passes) can lookup up whatever interesting attribute it wants and obtain the values in a fairly straightforward manner.</p><p class="p1"><br></p>
<p class="p1">I think this tends to work better than storing the names of kernels in a list hanging off from one NamedMDNode:</p>
<p class="p1">(1) passes can just concatenate the name of the function with a postfix and look up the metadata, there's no second phase of then searching through a list to find the name of the function it's interested in.</p>
<p class="p1">(2) it's not obvious how you're going to extend the list approach to carry attribute values. Suppose you add support for the work_group_size_hint (it carries 3 integer values) how are you proposing that the presence of the attribute and it's data be represented? </p>
<p class="p2"><br></p>
<p class="p1">Thanks, Krister.</p>
<p class="p2"><br></p><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 11:54 PM, Anton Lokhmotov <span dir="ltr"><<a href="mailto:Anton.Lokhmotov@arm.com">Anton.Lokhmotov@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Peter,<br>
<div class="im"><br>
> There are several examples of existing attributes in the Clang source<br>
> code which you should be able to follow. Perhaps you can explain in<br>
> more detail why you cannot use attributes here?<br>
<br>
</div>We feared that too much code would be generated when using attributes. (As<br>
you know, we must be cautious of anything negatively affecting the compiler<br>
footprint.) However, we've re-implemented the kernel function qualifier<br>
using an attribute instead of a field. Please review.<br>
<div class="im"><br>
<br>
> > + // OpenCL1.1 enables these extensions by default<br>
> > + cl_khr_global_int32_base_atomics =<br>
> > + cl_khr_global_int32_extended_atomics =<br>
> > + cl_khr_local_int32_base_atomics =<br>
> > + cl_khr_local_int32_extended_atomics =<br>
> > + cl_khr_byte_addressable_store = 1;<br>
><br>
> I presume you misread Table 4.3 from the spec, which states<br>
> that those extensions must be supported, which is not the same<br>
> thing as being enabled.<br>
<br>
</div>Indeed. They are disabled now.<br>
<div class="im"><br>
<br>
> Are you planning to have a mechanism for specifying which extensions<br>
> are supported by a particular implementation? My initial thoughts<br>
> are that we can add a member function to TargetInfo which returns an<br>
> OpenCLOptions struct containing this information.<br>
<br>
</div>Yes, something along these lines.<br>
<div class="im"><br>
<br>
> > + unsigned cl_fp_contract : 1; // OpenCL FP_CONTRACT state.<br>
><br>
> I'm not sure this should be an OpenCL-specific option. In future<br>
> we would like to support #pragma STDC FP_CONTRACT, and ideally we'd<br>
> like to be able to reuse OpenCL's FP_CONTRACT support. I'd suggest<br>
> just making this a Sema field.<br>
</div>...<br>
<div class="im">> You should split this PragmaHandler into separate handlers for<br>
> #pragma OPENCL FP_CONTRACT and #pragma OPENCL EXTENSION. Then<br>
> there's no need to do the string matching yourself, and it will<br>
> be easier to reuse the FP_CONTRACT support.<br>
<br>
</div>Good point. We've refactored FP_CONTRACT support into a separate<br>
ParseFPContractPragma method. Note that in OpenCL the default value is ON,<br>
whilst in C99 it is undefined.<br>
<div class="im"><br>
<br>
> Comments on the second patch to come...<br>
</div>I'm attaching it again for convenience...<br>
<br>
<br>
Many thanks,<br>
<font color="#888888">Anton.</font><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br>