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

[Renato Golin]

On 25 October 2014 10:02, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 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 the only cases are the ones that don't have back-ends, then the
solution is trivial: create empty back-ends for them that *just*
contains the target information, and all should behave identical.


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

That's the idea. I don't think that producing ARM IR on a native MIPS
compiler (or vice-versa) is a useful feature.


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

That's where it all started... :)

The problems I'm trying to tackle with this are:

1. http://llvm.org/PR20757: .fpu/.arch/.cpu asm directives don't
change the behaviour in assembly files as they should. The problem is
deeper and spawned a long discussion here and at the GCC list.

2. http://llvm.org/PR20787: assembler directives and command line
parsing have the same arguments and need a common parser.

These problems were the seed to this target info library that would
free all tools of repeating both the parsing and the identification of
any target specific knowledge or behaviour.

Once we have a common description, we can then fix the parser by
adding a TargetParser to the TargetInfo set of classes, and fix the
asm directives by changing the local behaviour of the architecture but
not the global (which will be in TargetInfo).

cheers,
--renato