llvm dev - Oct 2011 - [LLVMdev] ANN: libclc (OpenCL C library implementation)

Hi everybody,

the compiler design lab at Saarland University (chair of Sebastian Hack) 
is also working on an LLVM-based OpenCL driver.

The project started as a use-case for our "Whole-Function
Vectorization"
library, which allows to transform a function to compute the same as W 
executions of the original code by using SIMD instructions (W = 4 for 
SSE/AltiVec, 8 for AVX).

The algorithm, a few details on the OpenCL driver, and some results were 
published at CGO'11:
http://dx.doi.org/10.1109/CGO.2011.5764682

In contrast to Clover and pocl, we aimed at maximum performance before 
full support of the API (which simply requires more manpower than one 
PhD student).
The driver was evaluated using benchmarks from the AMD APP SDK, e.g. 
Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT, ...
Our measurements show that our driver outperforms both Intel's and AMD's
CPU driver for almost all of the benchmarks.

We plan to release both the vectorization library as well as the OpenCL 
driver under a BSD-style license, but there is still significant work to 
be done in terms of stability and feature completeness (e.g. the ICD 
mechanism only works as expected under Windows).
Also, due to simplicity we currently employ AMD's OpenCL-to-LLVM 
frontend and OpenCL-library from an earlier SDK. libclc sounds like the 
perfect fit for us to get rid of that.

I agree on the fact that we should try to merge the different 
open-source OpenCL projects, but at least at first glance they do not 
seem to share too many design decisions.

More information on Whole-Function Vectorization and our driver can be 
found on the project web page:
http://www.cdl.uni-saarland.de/projects/wfv

Best regards,
Ralf


Am 19.10.2011 17:38, schrieb Hal Finkel:
> Do we have a list of these open-source LLVM-based OpenCL projects
> somewhere? Off the top of my head, we have:
>
> libclc: http://www.pcc.me.uk/~peter/libclc/
> pocl: https://launchpad.net/pocl
> clover: http://cgit.freedesktop.org/~steckdenis/clover/
>
> (I think that all of these have BSD- or MIT-style licenses).
>
> Are there any others?
>
>   -Hal
>
> On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
>> Hi,
>>
>> This is to announce the availability of libclc, an open source, BSD
>> licensed implementation of the library requirements of the OpenCL C
>> programming language, as specified by the OpenCL 1.1 Specification.
>> libclc is intended to be used with Clang's OpenCL frontend.
>>
>> libclc website: http://www.pcc.me.uk/~peter/libclc/
>>
>> libclc is designed to be portable and extensible. To this end,
>> it provides generic implementations of most library requirements,
>> allowing the target to override the generic implementation at the
>> granularity of individual functions.
>>
>> libclc currently only supports the PTX target, but support for more
>> targets is welcome.
>>
>> How does this project relate to the recently announced Portable OpenCL
>> (POCL) project?  Unlike POCL, this project is not intended to provide
>> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
>> Runtime specified in sections 4-5 of the OpenCL specification).
>> Instead, it provides only the requirements for the OpenCL C
>> Programming Language (section 6 et seq).  It is intended to be used
>> with an existing host library implementation, and comply with its
>> ABI requirements.
>>
>> An example of such a host library is NVIDIA's OpenCL host library
>> for PTX -- the intention is to at some point provide a mechanism
>> for using the NVIDIA implementation of OpenCL with Clang, libclc
>> and LLVM's PTX backend instead of NVIDIA's own OpenCL compiler.
>> Another example would be POCL's host library, and the POCL
developers
>> have expressed an interest in using libclc as their OpenCL C library
>> instead of developing their own.
>>
>> I will hope to find time over the next few weeks to add libclc support
>> to the Clang driver.  The intention is that compiling OpenCL C programs
>> to PTX would be as easy as (something like this):
>>
>> clang -target ptx32 -S file.cl
>>
>> such that the driver would automatically locate the libclc headers,
>> add them to the include path and pre-include the main header file.
>> (The libclc support will of course be optional, and a
-cl-stdlib>> flag will be provided to allow for switching between OpenCL
standard
>> library implementations.)
>>
>> Thanks,
>

Ralf,
 What version of the SDK were you using for your analysis? I don't see that
in the slides/pdf.

Thanks,
Micah
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Ralf Karrenberg
> Sent: Wednesday, October 19, 2011 2:13 PM
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] ANN: libclc (OpenCL C library implementation)
> 
> Hi everybody,
> 
> the compiler design lab at Saarland University (chair of Sebastian
> Hack)
> is also working on an LLVM-based OpenCL driver.
> 
> The project started as a use-case for our "Whole-Function
> Vectorization"
> library, which allows to transform a function to compute the same as W
> executions of the original code by using SIMD instructions (W = 4 for
> SSE/AltiVec, 8 for AVX).
> 
> The algorithm, a few details on the OpenCL driver, and some results
> were
> published at CGO'11:
> http://dx.doi.org/10.1109/CGO.2011.5764682
> 
> In contrast to Clover and pocl, we aimed at maximum performance before
> full support of the API (which simply requires more manpower than one
> PhD student).
> The driver was evaluated using benchmarks from the AMD APP SDK, e.g.
> Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT,
> ...
> Our measurements show that our driver outperforms both Intel's and
> AMD's
> CPU driver for almost all of the benchmarks.
> 
> We plan to release both the vectorization library as well as the OpenCL
> driver under a BSD-style license, but there is still significant work
> to
> be done in terms of stability and feature completeness (e.g. the ICD
> mechanism only works as expected under Windows).
> Also, due to simplicity we currently employ AMD's OpenCL-to-LLVM
> frontend and OpenCL-library from an earlier SDK. libclc sounds like the
> perfect fit for us to get rid of that.
> 
> I agree on the fact that we should try to merge the different
> open-source OpenCL projects, but at least at first glance they do not
> seem to share too many design decisions.
> 
> More information on Whole-Function Vectorization and our driver can be
> found on the project web page:
> http://www.cdl.uni-saarland.de/projects/wfv
> 
> Best regards,
> Ralf
> 
> 
> Am 19.10.2011 17:38, schrieb Hal Finkel:
> > Do we have a list of these open-source LLVM-based OpenCL projects
> > somewhere? Off the top of my head, we have:
> >
> > libclc: http://www.pcc.me.uk/~peter/libclc/
> > pocl: https://launchpad.net/pocl
> > clover: http://cgit.freedesktop.org/~steckdenis/clover/
> >
> > (I think that all of these have BSD- or MIT-style licenses).
> >
> > Are there any others?
> >
> >   -Hal
> >
> > On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
> >> Hi,
> >>
> >> This is to announce the availability of libclc, an open source,
BSD
> >> licensed implementation of the library requirements of the OpenCL
C
> >> programming language, as specified by the OpenCL 1.1
Specification.
> >> libclc is intended to be used with Clang's OpenCL frontend.
> >>
> >> libclc website: http://www.pcc.me.uk/~peter/libclc/
> >>
> >> libclc is designed to be portable and extensible. To this end,
> >> it provides generic implementations of most library requirements,
> >> allowing the target to override the generic implementation at the
> >> granularity of individual functions.
> >>
> >> libclc currently only supports the PTX target, but support for
more
> >> targets is welcome.
> >>
> >> How does this project relate to the recently announced Portable
> OpenCL
> >> (POCL) project?  Unlike POCL, this project is not intended to
> provide
> >> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
> >> Runtime specified in sections 4-5 of the OpenCL specification).
> >> Instead, it provides only the requirements for the OpenCL C
> >> Programming Language (section 6 et seq).  It is intended to be
used
> >> with an existing host library implementation, and comply with its
> >> ABI requirements.
> >>
> >> An example of such a host library is NVIDIA's OpenCL host
library
> >> for PTX -- the intention is to at some point provide a mechanism
> >> for using the NVIDIA implementation of OpenCL with Clang, libclc
> >> and LLVM's PTX backend instead of NVIDIA's own OpenCL
compiler.
> >> Another example would be POCL's host library, and the POCL
> developers
> >> have expressed an interest in using libclc as their OpenCL C
library
> >> instead of developing their own.
> >>
> >> I will hope to find time over the next few weeks to add libclc
> support
> >> to the Clang driver.  The intention is that compiling OpenCL C
> programs
> >> to PTX would be as easy as (something like this):
> >>
> >> clang -target ptx32 -S file.cl
> >>
> >> such that the driver would automatically locate the libclc
headers,
> >> add them to the include path and pre-include the main header file.
> >> (The libclc support will of course be optional, and a
-cl-stdlib> >> flag will be provided to allow for switching between
OpenCL standard
> >> library implementations.)
> >>
> >> Thanks,
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Micah,

The numbers from the paper were measured with the ATI Stream SDK v2.1 
(it's only mentioned in the references I think).
The most recent measurements I have were done with the current v2.5.

Best,
Ralf

Am 19.10.2011 23:43, schrieb Villmow, Micah:
> Ralf,
>   What version of the SDK were you using for your analysis? I don't see
that in the slides/pdf.
>
> Thanks,
> Micah
>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
>> On Behalf Of Ralf Karrenberg
>> Sent: Wednesday, October 19, 2011 2:13 PM
>> To: llvmdev at cs.uiuc.edu
>> Subject: Re: [LLVMdev] ANN: libclc (OpenCL C library implementation)
>>
>> Hi everybody,
>>
>> the compiler design lab at Saarland University (chair of Sebastian
>> Hack)
>> is also working on an LLVM-based OpenCL driver.
>>
>> The project started as a use-case for our "Whole-Function
>> Vectorization"
>> library, which allows to transform a function to compute the same as W
>> executions of the original code by using SIMD instructions (W = 4 for
>> SSE/AltiVec, 8 for AVX).
>>
>> The algorithm, a few details on the OpenCL driver, and some results
>> were
>> published at CGO'11:
>> http://dx.doi.org/10.1109/CGO.2011.5764682
>>
>> In contrast to Clover and pocl, we aimed at maximum performance before
>> full support of the API (which simply requires more manpower than one
>> PhD student).
>> The driver was evaluated using benchmarks from the AMD APP SDK, e.g.
>> Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT,
>> ...
>> Our measurements show that our driver outperforms both Intel's and
>> AMD's
>> CPU driver for almost all of the benchmarks.
>>
>> We plan to release both the vectorization library as well as the OpenCL
>> driver under a BSD-style license, but there is still significant work
>> to
>> be done in terms of stability and feature completeness (e.g. the ICD
>> mechanism only works as expected under Windows).
>> Also, due to simplicity we currently employ AMD's OpenCL-to-LLVM
>> frontend and OpenCL-library from an earlier SDK. libclc sounds like the
>> perfect fit for us to get rid of that.
>>
>> I agree on the fact that we should try to merge the different
>> open-source OpenCL projects, but at least at first glance they do not
>> seem to share too many design decisions.
>>
>> More information on Whole-Function Vectorization and our driver can be
>> found on the project web page:
>> http://www.cdl.uni-saarland.de/projects/wfv
>>
>> Best regards,
>> Ralf
>>
>>
>> Am 19.10.2011 17:38, schrieb Hal Finkel:
>>> Do we have a list of these open-source LLVM-based OpenCL projects
>>> somewhere? Off the top of my head, we have:
>>>
>>> libclc: http://www.pcc.me.uk/~peter/libclc/
>>> pocl: https://launchpad.net/pocl
>>> clover: http://cgit.freedesktop.org/~steckdenis/clover/
>>>
>>> (I think that all of these have BSD- or MIT-style licenses).
>>>
>>> Are there any others?
>>>
>>>    -Hal
>>>
>>> On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
>>>> Hi,
>>>>
>>>> This is to announce the availability of libclc, an open source,
BSD
>>>> licensed implementation of the library requirements of the
OpenCL C
>>>> programming language, as specified by the OpenCL 1.1
Specification.
>>>> libclc is intended to be used with Clang's OpenCL frontend.
>>>>
>>>> libclc website: http://www.pcc.me.uk/~peter/libclc/
>>>>
>>>> libclc is designed to be portable and extensible. To this end,
>>>> it provides generic implementations of most library
requirements,
>>>> allowing the target to override the generic implementation at
the
>>>> granularity of individual functions.
>>>>
>>>> libclc currently only supports the PTX target, but support for
more
>>>> targets is welcome.
>>>>
>>>> How does this project relate to the recently announced Portable
>> OpenCL
>>>> (POCL) project?  Unlike POCL, this project is not intended to
>> provide
>>>> an OpenCL host library (i.e. the OpenCL Platform Layer and
OpenCL
>>>> Runtime specified in sections 4-5 of the OpenCL specification).
>>>> Instead, it provides only the requirements for the OpenCL C
>>>> Programming Language (section 6 et seq).  It is intended to be
used
>>>> with an existing host library implementation, and comply with
its
>>>> ABI requirements.
>>>>
>>>> An example of such a host library is NVIDIA's OpenCL host
library
>>>> for PTX -- the intention is to at some point provide a
mechanism
>>>> for using the NVIDIA implementation of OpenCL with Clang,
libclc
>>>> and LLVM's PTX backend instead of NVIDIA's own OpenCL
compiler.
>>>> Another example would be POCL's host library, and the POCL
>> developers
>>>> have expressed an interest in using libclc as their OpenCL C
library
>>>> instead of developing their own.
>>>>
>>>> I will hope to find time over the next few weeks to add libclc
>> support
>>>> to the Clang driver.  The intention is that compiling OpenCL C
>> programs
>>>> to PTX would be as easy as (something like this):
>>>>
>>>> clang -target ptx32 -S file.cl
>>>>
>>>> such that the driver would automatically locate the libclc
headers,
>>>> add them to the include path and pre-include the main header
file.
>>>> (The libclc support will of course be optional, and a
-cl-stdlib>>>> flag will be provided to allow for switching between
OpenCL standard
>>>> library implementations.)
>>>>
>>>> Thanks,
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

Hi Ralf,
> I agree on the fact that we should try to merge the different 
> open-source OpenCL projects, but at least at first glance they do not 
> seem to share too many design decisions.
One of the primary goals of libclc is to pool efforts between OpenCL
implementations in terms of implementing the large proportion of OpenCL C
builtin functions which can be implemented generically, since this task is
tedious and hardly ever the focus of any individual implementation but is a
conformance requirement.  I therefore consider libclc to be an important
step towards merging OpenCL projects.
> In contrast to Clover and pocl, we aimed at maximum performance before
> full support of the API (which simply requires more manpower than one
> PhD student). 
I was in a similar position when I decided to start the libclc
project.  While my ultimate goal was not performance, the sheer
number of built-in functions was far too much for my one-man research
project to handle.  What libclc represents right now are the generic
functions I have implemented so far as part of this project, plus a
few new functions.
> Also, due to simplicity we currently employ AMD's OpenCL-to-LLVM 
> frontend and OpenCL-library from an earlier SDK. libclc sounds like the 
> perfect fit for us to get rid of that.
Great.  If you do decide to get involved in libclc development,
please get in touch on the mailing list:
http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev

Thanks,
-- 
Peter

>The driver was evaluated using benchmarks from the AMD APP SDK, e.g. 
>Mandelbrot, NBody, FastWalshTransform, Histogram, BlackScholes, DCT, ...
>Our measurements show that our driver outperforms both Intel's and
AMD's
>CPU driver for almost all of the benchmarks.

The latest Intel OpenCL SDK with our vectorization technology is available here:

http://software.intel.com/en-us/articles/opencl-sdk/

I'd be happy to see the numbers for the comparisons that you've made.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Hi Ralf,
> The project started as a use-case for our "Whole-Function
Vectorization"
> library, which allows to transform a function to compute the same as W 
> executions of the original code by using SIMD instructions (W = 4 for 
> SSE/AltiVec, 8 for AVX).
Quite interesting. We were planning to add "vectorization" to our
passes also, but if I understood the paper correctly your approach uses full
speculation, which is all right for SIMD architectures but might not be so for
multi-issue processors. The pocl project comes from a generalization of our work
in using OpenCL as entry language for static ILP architectures
(http://dx.doi.org/10.1109/ICSAMOS.2010.5642061), so we do not only focus on DLP
but also ILP (ultimate goal of pocl is portable performance of OpenCL code among
different platforms).

Our idea was to use an hybrid method, with vectorized code in the unconditional
sections and replicated/looped as we do now on the conditional parts of the
kernels.
> In contrast to Clover and pocl, we aimed at maximum performance before 
> full support of the API (which simply requires more manpower than one 
> PhD student).
That is wrong, at least for pocl. We do not (by far) support the whole API, the
main new point on pocl is the LLVM passes to statically create the different
work items in a workgroup, and the barrier handling. Our kernel runtime library
is currently in fact fairly small, including just a little more then the
implementation-dependent functions. We are considering merging efforts with
liblcl in that point.

BR,

Carlos
> Am 19.10.2011 17:38, schrieb Hal Finkel:
>> Do we have a list of these open-source LLVM-based OpenCL projects
>> somewhere? Off the top of my head, we have:
>> 
>> libclc: http://www.pcc.me.uk/~peter/libclc/
>> pocl: https://launchpad.net/pocl
>> clover: http://cgit.freedesktop.org/~steckdenis/clover/
>> 
>> (I think that all of these have BSD- or MIT-style licenses).
>> 
>> Are there any others?
>> 
>>  -Hal
>> 
>> On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
>>> Hi,
>>> 
>>> This is to announce the availability of libclc, an open source, BSD
>>> licensed implementation of the library requirements of the OpenCL C
>>> programming language, as specified by the OpenCL 1.1 Specification.
>>> libclc is intended to be used with Clang's OpenCL frontend.
>>> 
>>> libclc website: http://www.pcc.me.uk/~peter/libclc/
>>> 
>>> libclc is designed to be portable and extensible. To this end,
>>> it provides generic implementations of most library requirements,
>>> allowing the target to override the generic implementation at the
>>> granularity of individual functions.
>>> 
>>> libclc currently only supports the PTX target, but support for more
>>> targets is welcome.
>>> 
>>> How does this project relate to the recently announced Portable
OpenCL
>>> (POCL) project?  Unlike POCL, this project is not intended to
provide
>>> an OpenCL host library (i.e. the OpenCL Platform Layer and OpenCL
>>> Runtime specified in sections 4-5 of the OpenCL specification).
>>> Instead, it provides only the requirements for the OpenCL C
>>> Programming Language (section 6 et seq).  It is intended to be used
>>> with an existing host library implementation, and comply with its
>>> ABI requirements.
>>> 
>>> An example of such a host library is NVIDIA's OpenCL host
library
>>> for PTX -- the intention is to at some point provide a mechanism
>>> for using the NVIDIA implementation of OpenCL with Clang, libclc
>>> and LLVM's PTX backend instead of NVIDIA's own OpenCL
compiler.
>>> Another example would be POCL's host library, and the POCL
developers
>>> have expressed an interest in using libclc as their OpenCL C
library
>>> instead of developing their own.
>>> 
>>> I will hope to find time over the next few weeks to add libclc
support
>>> to the Clang driver.  The intention is that compiling OpenCL C
programs
>>> to PTX would be as easy as (something like this):
>>> 
>>> clang -target ptx32 -S file.cl
>>> 
>>> such that the driver would automatically locate the libclc headers,
>>> add them to the include path and pre-include the main header file.
>>> (The libclc support will of course be optional, and a
-cl-stdlib>>> flag will be provided to allow for switching between
OpenCL standard
>>> library implementations.)
>>> 
>>> Thanks,
>> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/e33137d1/attachment.html>

Hi Carlos,

On 10/20/11 9:54 AM, Carlos Sánchez de La Lama wrote:
>> The project started as a use-case for our "Whole-Function
Vectorization"
>> library, which allows to transform a function to compute the same as W
>> executions of the original code by using SIMD instructions (W = 4 for
>> SSE/AltiVec, 8 for AVX).
>
> Quite interesting. We were planning to add "vectorization" to our
passes
> also, but if I understood the paper correctly your approach uses full
> speculation, which is all right for SIMD architectures but might not be
> so for multi-issue processors.
I don't know what you mean with "speculation" here, but other than
that
you are right: for best performance, we explicitly target machines with 
SIMD instruction sets.
>> In contrast to Clover and pocl, we aimed at maximum performance before
>> full support of the API (which simply requires more manpower than one
>> PhD student).
>
> That is wrong, at least for pocl. We do not (by far) support the whole
> API, the main new point on pocl is the LLVM passes to statically create
> the different work items in a workgroup, and the barrier handling. Our
> kernel runtime library is currently in fact fairly small, including just
> a little more then the implementation-dependent functions. We are
> considering merging efforts with liblcl in that point.
Please excuse me for getting that wrong.

I think we should really stick our heads together (also including Denis 
Steckelmacher who implemented Clover) and somehow combine all our efforts.
Otherwise, we will probably just all solve the same problems in 
parallel. Additionally, no user will gain anything if he has to decide 
between multiple, half-baked solutions.

Best,
Ralf


>> Am 19.10.2011 17:38, schrieb Hal Finkel:
>>> Do we have a list of these open-source LLVM-based OpenCL projects
>>> somewhere? Off the top of my head, we have:
>>>
>>> libclc: http://www.pcc.me.uk/~peter/libclc/
>>> pocl: https://launchpad.net/pocl
>>> clover: http://cgit.freedesktop.org/~steckdenis/clover/
>>>
>>> (I think that all of these have BSD- or MIT-style licenses).
>>>
>>> Are there any others?
>>>
>>> -Hal
>>>
>>> On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:
>>>> Hi,
>>>>
>>>> This is to announce the availability of libclc, an open source,
BSD
>>>> licensed implementation of the library requirements of the
OpenCL C
>>>> programming language, as specified by the OpenCL 1.1
Specification.
>>>> libclc is intended to be used with Clang's OpenCL frontend.
>>>>
>>>> libclc website: http://www.pcc.me.uk/~peter/libclc/
>>>>
>>>> libclc is designed to be portable and extensible. To this end,
>>>> it provides generic implementations of most library
requirements,
>>>> allowing the target to override the generic implementation at
the
>>>> granularity of individual functions.
>>>>
>>>> libclc currently only supports the PTX target, but support for
more
>>>> targets is welcome.
>>>>
>>>> How does this project relate to the recently announced Portable
OpenCL
>>>> (POCL) project? Unlike POCL, this project is not intended to
provide
>>>> an OpenCL host library (i.e. the OpenCL Platform Layer and
OpenCL
>>>> Runtime specified in sections 4-5 of the OpenCL specification).
>>>> Instead, it provides only the requirements for the OpenCL C
>>>> Programming Language (section 6 et seq). It is intended to be
used
>>>> with an existing host library implementation, and comply with
its
>>>> ABI requirements.
>>>>
>>>> An example of such a host library is NVIDIA's OpenCL host
library
>>>> for PTX -- the intention is to at some point provide a
mechanism
>>>> for using the NVIDIA implementation of OpenCL with Clang,
libclc
>>>> and LLVM's PTX backend instead of NVIDIA's own OpenCL
compiler.
>>>> Another example would be POCL's host library, and the POCL
developers
>>>> have expressed an interest in using libclc as their OpenCL C
library
>>>> instead of developing their own.
>>>>
>>>> I will hope to find time over the next few weeks to add libclc
support
>>>> to the Clang driver. The intention is that compiling OpenCL C
programs
>>>> to PTX would be as easy as (something like this):
>>>>
>>>> clang -target ptx32 -S file.cl
>>>>
>>>> such that the driver would automatically locate the libclc
headers,
>>>> add them to the include path and pre-include the main header
file.
>>>> (The libclc support will of course be optional, and a
-cl-stdlib>>>> flag will be provided to allow for switching between
OpenCL standard
>>>> library implementations.)
>>>>
>>>> Thanks,
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>