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

[Douglas Katzman]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150605/1a1ed713/attachment.html>