[LLVMdev] ANN: libclc (OpenCL C library implementation)

Marc J. Driftmeyer mjd at reanimality.com
Thu Oct 20 20:28:02 PDT 2011

I was hoping you would come to the collaborative, joint solution. I've 
been waiting for Clang to have a settled OpenCL implementation to start 
working on OpenCL.

Dealing with 3 parallel projects would be just that, a pain in the rear.

- Marc

On 10/20/2011 03:45 AM, Ralf Karrenberg wrote:
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Marc J. Driftmeyer
Email :: mjd at reanimality.com <mailto:mjd at reanimality.com>
Web :: http://www.reanimality.com
Cell :: (509) 435-5212
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/7832e65a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mjd.vcf
Type: text/x-vcard
Size: 317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111020/7832e65a/attachment.vcf>

More information about the llvm-dev mailing list