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
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 Movidius1. 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
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
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
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 March1 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
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?
Quite possibly. However, we’re currently just trying to get Clang to work better with the existing tools and explicitly offloaded code. Leveraging OpenMP offloading (or any other form of automatic offloading) would be a somewhat different effort I suspect.