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

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

David

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

On Sat, Oct 25, 2014 at 5:01 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> 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.
>
I think this is OK for PNaCl.

What David is suggesting is interesting though: what if a target wanted to
have ARM, x86 and MIPS assembly all assembled in a single executable at the
end (not PNaCl's usecase)? It seems like you could just create separate .o
and merge them later, no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141025/ff1706ed/attachment.html>