<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [cfe-dev] OpenCL support</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>-----Original Message-----<BR>
From: cfe-dev-bounces@cs.uiuc.edu on behalf of Anton Lokhmotov<BR>
Sent: Fri 10/12/2010 18:21<BR>
To: cfe-dev@cs.uiuc.edu<BR>
Subject: [cfe-dev] OpenCL support<BR>
<BR>
> 1) For kernel functions (with the __kernel qualifier), we insert named<BR>
> metadata nodes into LLVM-IR. Other options we have evaluated included:<BR>
> - Shipping metadata separately from bitcode. This would be hard to<BR>
> standardise on and maintain.<BR>
> - Using imaginative name mangling. This would be pretty horrible too and<BR>
> easy to misuse.<BR>
><BR>
> The drawback of course is that metadata can be "silently dropped". However,<BR>
> we are not aware of any transforms that would do this. Perhaps the<BR>
> community should consider defining "sticky metadata"?<BR>
<BR>
You could also consider placing all kernel functions in a 'kernel' section, or<BR>
adding a function attribute for kernels.<BR>
<BR>
Inserting metadata feels a little dirty to me, it shouldn't be used if it would change<BR>
the semantics of the program (which it would in this case). Some kind of 'sticky' metadata<BR>
would indeed get around 'dropping', however I don't believe (I may be wrong) that metadata was<BR>
designed for this purpose. I'm not sure that trying to fit it to this purpose is a good idea.<BR>
<BR>
<BR>
> Please review and comment.<BR>
<BR>
cl_khr_byte_addressable_store is probably a fairly well supported 1.0 extension that<BR>
you could add too :) Those will have to be disabled by default for 1.0 anyhow.<BR>
<BR>
Regards,<BR>
Mike<BR>
</FONT>
</P>
</BODY>
</HTML>