[LLVMdev] [cfe-dev] Target specific info available to Clang (and others)

David Chisnall David.Chisnall at cl.cam.ac.uk
Sat Oct 25 02:02:40 PDT 2014

On 24 Oct 2014, at 18:17, Renato Golin <renato.golin at linaro.org> wrote:

> I'm beginning to think that the "nice" feature 1 is not worth the two
> big problems 2 and 3. If we tie Clang builds with back-end builds and
> force it not to have support for other arches (because the info isn't
> available if you don't build its back-end), than all that info can
> still be public and not completely bloat the final libraries.
> Is there any stronger reason why Clang must be able to generate IR for
> any arch on any arch?

To clarify: Are you asking if there's a use case for clang being able to generate IR for architectures that it can't generate native code for?  The only cases I can think of for this are special targets (SPIR, PNaCl), where there isn't a corresponding back end.

If we can reduce the size of a build of clang that isn't a cross compiler, without reducing the utility of a build of clang that is a cross compiler, then this sounds like a good plan.  We generally have two uses for clang:

- On big machines, we want a few symlinks to clang for different targets

- On small machines, we want as small a clang as possible, with only the features that are absolutely essential as a C compiler

While we're discussing target-specific things though, there is one corner case that's come up a few times and is worth considering:

A few people want to target a lowest-common-denominator architecture for most of the code and have some functions use intrinsics of inline assembly relying on features for something more specific (e.g. x86-64 base, SSE 4.2 in some functions) and then decide whether to use those specific functions at run time.

We actually have a more general case of this, where we'd like to be able to embed some inline MIPS assembly in x86 and ARM binaries that are going to be used for controlling a MIPS-compatible coprocessor (or talking to it over JTAG).  


More information about the llvm-dev mailing list