[cfe-dev] embedded CPUs, or making Clang's driver more flexible / not so omniscient

[Chandler Carruth]

I just wanted to follow up here with more concrete context on what we're
working on for folks.

We'd like to be able to use Clang with the Myriad 2 platform from
Movidius[1]. These chips have accelerators (called SHAVEs) that are
targeted by a special compiler and other tools in their dev kit (the MDK).
We want to use the Clang driver when targeting the platform, with normal
Clang and LLVM targeting the CPU and using the custom compiler for code
targeting the special SHAVE processors.

Hope that helps people understand the use case here.

-Chandler

[1]: http://www.movidius.com/our-technology/myriad-2-platform/

On Fri, Jun 5, 2015 at 10:03 AM Douglas Katzman <dougk at google.com> wrote:

> Hi folks,
>
> I put a small change up on Phabricator which has gotten more lines of
> feedback than lines of source touched, so at the suggestion of the reviewer
> (Chandler) I'd like to call attention to the limitation this patch starts
> to address. http://reviews.llvm.org/D10246
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10246&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=isl0i6sDYGuKgTCVwNhPlRv7CkLfyBPym7wDaDauND8&s=gyWrhthaKH3hzoAPgD3k1YIbz5Q_QExs0JHB_ozrjbw&e=>
>
> Suppose you want to generate code for some uncommon chip. The hardware
> manufacturer gives you a C compiler and assembler that are ostensibly black
> boxes- they might use pieces of llvm, but we don't know / don't care,
> initially anyway.
>
> If your workflow entails always running 'clang' as your compiler, what
> you'd like is that invoking clang with '-target=dinglehopper250x' runs the
> opaque tools.
> This is either a migration path or a permanent solution depending on
> whether llvm support will eventually exist.
>
> For this to work, it's a straightforward matter to add a backend name to
> llvm that it can't generate code for, have that backend pick a toolchain
> with custom behavior, and then modify ConstructJob to produce arguments to
> the foreign tools.
> To avoid users having to know that the vendor-provided compiler has to be
> invoked with various mystery options, we can put the options into the clang
> driver, which will add them in when it sees that specific target
> architecture.
>
> The problem one encounters immediately is that the clang driver thinks
> that the clang compiler is always the right tool to compile C. This logic
> is ingrained in 'types::isAcceptedByClang' and
> 'Driver::ShouldUseClangCompiler' which return true for the C family.
> My patch makes it possible for the ToolChain itself (the clang object that
> models the external command-line programs) to make that decision.
>
> Please let me know if the above is clear and/or whether "there's a better
> way."
>
> Doug
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150605/88933e2f/attachment.html>