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

[Samuel F Antao]

Hi all,

I probably do not fully understand the programing model behind the Myriad 2
platform, but based on the explanation I seem to detect some overlap with
the OpenMP offloading programing model. We have a patch that proposes some
changes in the driver to support OpenMP offloading -
http://reviews.llvm.org/D9888 - however, it does not propose to use
anything different from Clang. Could this platform benefit from anything we
are proposing in there?

Thanks,
Samuel

2015-06-05 15:15 GMT-04:00 Chandler Carruth <chandlerc at google.com>:

> 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/1ffb1bf9/attachment.html>