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

[Jim Grosbach]

This makes a lot of sense to me. Better support for this sort of use case will be very welcome.

Can you expand a bit on the direction for this target in particular? Is the end goal to improve the interworking with the existing toolchain, to bring up a full llvm target, some mix of both?

Jim

> On Jun 5, 2015, at 12:15 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 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
>> 
>> 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
> _______________________________________________
> 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/20150608/b4a724eb/attachment.html>