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

[Chandler Carruth]

On Mon, Jun 8, 2015 at 1:55 PM Jim Grosbach <grosbach at apple.com> wrote:

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

Awesome, as there seems to be general support, I'll probably LGTM Doug's
patch here shortly. Please keep the questions coming as useful.


>
> 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?
>

Currently, our focus is to improve how Clang and LLVM work with the
existing dev kit and toolchain.

The company in question started a thread back in March[1] that seemed to be
related to bringing up a full LLVM target, but I don't know the status of
that effort. Of course, IMO, it would be really nice to have full LLVM
support here, so I'm very supportive of that whole direction.

-Chandler

[1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/083997.html


>
> 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.movidius.com_our-2Dtechnology_myriad-2D2-2Dplatform_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=vYtmGebCDsug_Hs1i6g07OAR60cASC_ssw073YrxSj4&s=lPhmQ-d9wtVmDzwWqjUxwW7eehWINU70R451XtcCVF8&e=>
>
> 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
>>
> _______________________________________________
> 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/54f71e44/attachment.html>