OpenCL C

Clang Frontend
1

Hey,

I was wondering why OpenCL C is not listed in the Clang's
supported languages in the front page? It's now quite well
supported and is also a "C family language". Why it's not
a "1st class language" in Clang/LLVM?

Another thing is that I see no CODE_OWNERS.txt entry for
OpenCL C (perhaps SPIR also?). Is there someone that has
the "final word" on patches/commits related to OpenCL support, or
volunteering/willing to be one? I think if someone claimed
that responsibility "officially", it would accelerate the
progress towards improved open source OpenCL C support.

Thanks,

2

I was wondering why OpenCL C is not listed in the Clang's
supported languages in the front page? It's now quite well
supported and is also a "C family language". Why it's not
a "1st class language" in Clang/LLVM?

Hi Pekka,

I may be completely wrong, but I think the OpenCL users have mixed feelings
about a truly open source compiler. The lack of proper support in Clang (as
you state), the existence of many other alternatives (like Clover and all
proprietary ones) tells me that the support in Clang won't really fly
unless someone cares enough about it.

Another thing is that I see no CODE_OWNERS.txt entry for

OpenCL C (perhaps SPIR also?). Is there someone that has
the "final word" on patches/commits related to OpenCL support, or
volunteering/willing to be one? I think if someone claimed
that responsibility "officially", it would accelerate the
progress towards improved open source OpenCL C support.

A code owner is not just the final word on the subject, but even more than
that, it's whomever is interested enough and know who to ask for expert
reviews, to progress with a feature, and not let anyone mess up.

In light of that, if you care enough about it, and don't mind being
included in patch proposals and merge requests, or spending a little extra
time reviewing patches or bugging the right people to do so, I think you
could easily be the code owner for OpenCL.

My tuppence.

cheers,
--renato

3

Hi Renato,

I may be completely wrong, but I think the OpenCL users have mixed
feelings about a truly open source compiler. The lack of proper support
in Clang (as you state), the existence of many other alternatives (like
Clover and all proprietary ones) tells me that the support in Clang
won't really fly unless someone cares enough about it.

I think there are people who do care about open source, and/or see
the disadvantages of a bunch of (private or not) diverged Clang
branches that implement the same features.

AFAIK Clover, like pocl, uses (or at least tries to) the upstream Clang
for an OpenCL C frontend. There are not many unimplemented features of
the OpenCL 1.2 language in Clang that I know of anymore.

In light of that, if you care enough about it, and don't mind being
included in patch proposals and merge requests, or spending a little
extra time reviewing patches or bugging the right people to do so, I
think you could easily be the code owner for OpenCL.

I'm afraid I'm still too novice with the Clang internals to
be competent for this task. I hoped SomeOneElse(tm) raised his/her
hand to take this job :stuck_out_tongue: I can promise to do my best in reviewing
any patches though.

In any case, I do not understand why OpenCL C is treated as a kind of
a 2nd class language in Clang now, at least I get that feeling of it.

BR,

4

AFAIK Clover, like pocl, uses (or at least tries to) the upstream Clang
for an OpenCL C frontend. There are not many unimplemented features of
the OpenCL 1.2 language in Clang that I know of anymore.

Hi Pekka,

Genuine question: why are there two (more?) variants using LLVM?

I may be wrong, but I think this would be a major milestone to get the
"approved technology" stamp.

I'm afraid I'm still too novice with the Clang internals to

be competent for this task. I hoped SomeOneElse(tm) raised his/her
hand to take this job :stuck_out_tongue: I can promise to do my best in reviewing
any patches though.

That's great! Other things involve monitoring the mailing list for "opencl"
(with a filter, mark as important, etc), so that you respond to queries,
open bugs, find out more information, copy yourself to all bugs, make sure
they progress, etc. You don't need to be the code owner to do any of that.

In any case, I do not understand why OpenCL C is treated as a kind of

a 2nd class language in Clang now, at least I get that feeling of it.

There are no guarantees that it will work on every release.

The ARM back-end used to be second-class because even though there were
some buildbots, they would randomly fail, the test-suite wasn't passing and
not many people outside Apple would add code to it.

Since a few years ago, ARM got interest, and this year Linaro, Qualcomm and
others joined the crew and we have this amazing group of developers adding
features and fixing bugs, we have lots of buildbots and the test-suite
passes green every time, and every release we bootstrap, test, benchmark,
and make binary releases. It's a lot of work to be able to stamp
"first-class" on something, but it's worth it.

As long as all OpenCL parties hide behind proprietary curtains, this
integration will never happen, and it'd be hard to say OpenCL is
first-class. I don't think they will come, but there could be a large
enough community around it in the open, which will eventually make it
first-class, and drive OpenCL users into the open. But you have to do that
from the outside.

cheers,
--renato

5

Speaking in a personal capacity,

6

AFAIK OpenCL doesn't have a concrete specification, or the one you have is
not concrete enough in some places, and too concrete in others.

You can create perfectly valid Dwarf that no debugger in the world can
digest. You can create perfectly valid ELF objects that won't link with
others. You can parse C++ into a parfectly valid AST, but if you can't
build proper (target-specific) IR from it, it's useless.

For instance, if there is an official (Kronos-certified) parser that tells
you whether a piece of OpenCL IR/AST conforms to the standard, that's a
starter. If there is an emulator that executes OpenCL on the CPU as if it
were some GPU, that's better. If there is a standard CPU implementation
that will be actually used in production (like the Intel one), that's a lot
better.

But without any of these, I can't see how can we say something is
"supported".

cheers,
--renato

7

OpenCL C is a language, same as C or C++ or Objective C. There is a well-defined standard that is so close to C that it actually mostly describes the differences to C, and I assume that in practice this is the most useful thing to do to ensure clang treats it correctly. A C compiler doesn't need to provide an implementation of sqrt() or system(), and in fact clang doesn't -- and thus, and OpenCL C compiler doesn't need to provide a library either.

OpenCL C runs just fine on all platforms, including CPUs and GPUs, and no GPU emulator is needed to run it on CPUs or to examine correctness.

Think of OpenCL C as C, with explicit support for vector data types added (i.e. a better syntax for attribute((ext_vector_type(n)))), and where the sizes of the standard data types (short, int, long, float, double) are defined by the standard and not left to the implementation. Most other changes are minor, or refer to the standard library only.

I think OpenCL C is ready to be a first-class language in clang.

-erik

8

Do you have something like this for OpenCL C?

http://clang.llvm.org/cxx_status.html

cheers,
--renato

9

Genuine question: why are there two (more?) variants using LLVM?

The current conclusion of attempts to merge more of efforts (not
only via the Clang language support) between Clover/libclc and pocl
can be read here:
http://sourceforge.net/mailarchive/message.php?msg_id=31626357

I may be wrong, but I think this would be a major milestone to get the
"approved technology" stamp.

I still think the libraries and other supporting infrastructure
is separate from the language support in this question. Isn't this
like saying libstdc++ and libc++ should merge before one can stamp C++ as 1st class? Unfortunately the open source world is not ideal in
this regard either.

If one needs to execute compiled OpenCL test cases (static checks of
produced bitcode output are not enough) to believe they work,
then I'd rely on a full OpenCL implementation's test suite like
the one of pocl.

For the specification issue. If the specs leaves some things open/vague,
it's the problem of the specs? It's an implementation dependent detail
then? OpenCL C is derived from C99 and adds some features which one
can state that are supported or not, in a language status
table like there is for the C++ features. Ultimately it's the
Khronos' conformance test that says whether an implementation is
conformant or not. Hopefully some day that will also happen for
an open source implementation.

I agree with David that the test suite in the Clang side should
invclude also (more?) negative test cases for the language
errors/diagnostics for things that are not allowed in OpenCL C
(but might be in C99).

10

Can we have that running as a buildbot?

cheers,
--renato

11

As ever my personal views:

12

> I'll note that all those issues primarily of big import to a back-end
(or possibly a complete compiler). The situation with common, open-source
OpenCL is it is primarily in terms of modifications to the clang front-end
to be able to generate fully accurate AST's for OpenCL and ot issue correct
and informative diagnostics. It would be useful to see what sort of
consensus the community arises as to what ought to be being done for this
case: for a front end I suspect it's going to be generating a lot more test
cases to ensure features can only be used where the OpenCL specifications
allow them to be.
>
> AFAIK OpenCL doesn't have a concrete specification, or the one you have
is not concrete enough in some places, and too concrete in others.
>
> You can create perfectly valid Dwarf that no debugger in the world can
digest. You can create perfectly valid ELF objects that won't link with
others. You can parse C++ into a parfectly valid AST, but if you can't
build proper (target-specific) IR from it, it's useless.
>
> For instance, if there is an official (Kronos-certified) parser that
tells you whether a piece of OpenCL IR/AST conforms to the standard, that's
a starter. If there is an emulator that executes OpenCL on the CPU as if it
were some GPU, that's better. If there is a standard CPU implementation
that will be actually used in production (like the Intel one), that's a lot
better.
>
> But without any of these, I can't see how can we say something is
"supported".

OpenCL C is a language, same as C or C++ or Objective C. There is a
well-defined standard

I disagree. The OpenCL standard is very imprecise, to the point where we
frequently *cannot tell* whether a proposed patch to implement an OpenCL
feature is correct by reference to the standard. As far as I know, we don't
have any active contributing members of the Clang community who are
sufficiently closely linked to the OpenCL standardization process to answer
our questions (and maybe get the standard fixed in the process).

I think OpenCL C is ready to be a first-class language in clang.

We need people to step forward who are willing and able to divine the
intent of the OpenCL standard, determine what's missing, implement the
missing features, and support this configuration in the long term.

13

That would be great, but unfortunately it costs money to
get the conformance suite and probably comes with NDAs.
Perhaps it will be possible to get the suite by some
means, and install a private buildbot for it at some point.

For now I think a way to proceed would be to create a
table like the mentioned http://clang.llvm.org/cxx_status.html
for features described in the OpenCL 1.2 (and later 2.x)
specs and start crossing out what is done. Perhaps
refer to (sub)sections and even sentences in the
specs that deal with the kernel language. I can
start it when I get some time.

About the vagueness of the specs. We can forward those
issues to Khronos and hopefully they'll correct it
in the future specs releases. Until that we just
interpret the vague spots as we see fit?

https://www.khronos.org/bugzilla/

14

That would be great, but unfortunately it costs money to
get the conformance suite and probably comes with NDAs.
Perhaps it will be possible to get the suite by some
means, and install a private buildbot for it at some point.

If any company that already has the NDA signed could host this internally
and just report what's not working (even vaguely), it'd be awesome.

For now I think a way to proceed would be to create a

table like the mentioned Clang - C++ Programming Language Status
for features described in the OpenCL 1.2 (and later 2.x)
specs and start crossing out what is done. Perhaps
refer to (sub)sections and even sentences in the
specs that deal with the kernel language. I can
start it when I get some time.

That'd would be great!

About the vagueness of the specs. We can forward those

issues to Khronos and hopefully they'll correct it
in the future specs releases. Until that we just
interpret the vague spots as we see fit?

I won't pretend the C++ spec is not vague, or that we have a certified C++
suite (like PlumHall), but we have some alternatives and a massive body of
C++ code compiled with Clang as empirical data to rely on. There is nothing
like that for OpenCL.

But I wouldn't hold my breath for any change in the spec that has no
commercial backing. The Kronos group is not a community...

cheers,
--renato

15

Hi, Pekka

Nice work on pocl.
Just some personal thoughts.
From users perspective, what they need is OpenCL running on a vendor specific target device. The thing is, while the OpenCL standard is open, which means technically we could work out a production level frontend on top of Clang, the backend is usually vendor specific and proprietary. For the open source community developers, the limited accessibility to vendor specific target details makes it hard to produce a complete competitive solution for the end user. For device vendors, it’s relatively easier to construct a OpenCL frontend with Clang.
This partially explains why there are so many alternative OpenCL solutions, yet there is still no competitive open source solution for the end user.

Cheers.
-Guoping