[cfe-dev] OpenCL C

Renato Golin renato.golin at linaro.org
Tue Dec 17 08:44:37 PST 2013


On 17 December 2013 16:35, David Tweed <david.tweed at gmail.com> wrote:

> 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".

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131217/cc0c9f49/attachment.html>


More information about the cfe-dev mailing list