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

> On Oct 24, 2014, at 5:43 AM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
> On 24 October 2014 08:33, Renato Golin <renato.golin at linaro.org
<mailto:renato.golin at linaro.org>> wrote:
>> On 24 October 2014 13:13, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>>> lib/Target/ARM: only built if the ARM target is enabled.
>>> lib/TargetInfo/ARM: always build. Include only info that clang
wants
>>> to use: parse fpu name, construct the datalayout.
>> 
>> Yes! That's the final plan!
>> 
>> So, TableGen would generate two sets of files, one public and another
>> private. The former only containing high-level target descriptions,
>> cpu names, feature combinations, etc and the latter containing
>> everything else, from instructions to pipeline descriptions.
>> 
>> The public stuff should be available somewhere other projects can
>> access without having access to the other local files by accident.
>> Projects should not include them directly, but they'll include
files
>> that include them, so the directory should be in the projects'
paths,
>> too. We also may need to get these new classes into a library on its
>> own, no?
> 
> Yes, a fpu-name to fpu-enum function would live is such  a library. In
> the above example TargetInfo would not be just a directory
> organization,  there would be a lib/libLLVMTargetInfo.a in the build
> directory.
We also need a way to know which intrinsics are available for the current
target. Currently clang accepts all of them and you get a “cannot select” error
from the backend if the intrinsic is not available. We now have the mechanism to
provide a better diagnostic from the backend, but clang will do a better job of
getting the source location right…. except that clang currently has no way to
know details of the targets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/88b9b25d/attachment.html>

Sent from my iPhone
> On Oct 24, 2014, at 12:48, Bob Wilson <bob.wilson at apple.com>
wrote:
> 
> 
>> On Oct 24, 2014, at 5:43 AM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> 
>>> On 24 October 2014 08:33, Renato Golin <renato.golin at
linaro.org> wrote:
>>>> On 24 October 2014 13:13, Rafael Espíndola <rafael.espindola
at gmail.com> wrote:
>>>> lib/Target/ARM: only built if the ARM target is enabled.
>>>> lib/TargetInfo/ARM: always build. Include only info that clang
wants
>>>> to use: parse fpu name, construct the datalayout.
>>> 
>>> Yes! That's the final plan!
>>> 
>>> So, TableGen would generate two sets of files, one public and
another
>>> private. The former only containing high-level target descriptions,
>>> cpu names, feature combinations, etc and the latter containing
>>> everything else, from instructions to pipeline descriptions.
>>> 
>>> The public stuff should be available somewhere other projects can
>>> access without having access to the other local files by accident.
>>> Projects should not include them directly, but they'll include
files
>>> that include them, so the directory should be in the projects'
paths,
>>> too. We also may need to get these new classes into a library on
its
>>> own, no?
>> 
>> Yes, a fpu-name to fpu-enum function would live is such  a library. In
>> the above example TargetInfo would not be just a directory
>> organization,  there would be a lib/libLLVMTargetInfo.a in the build
>> directory.
> 
> We also need a way to know which intrinsics are available for the current
target. Currently clang accepts all of them and you get a “cannot select” error
from the backend if the intrinsic is not available. We now have the mechanism to
provide a better diagnostic from the backend, but clang will do a better job of
getting the source location right…. except that clang currently has no way to
know details of the targets.
Yes, that would be a reasonable thing to put in the library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141024/9c830156/attachment.html>

On 24 October 2014 17:48, Bob Wilson <bob.wilson at apple.com>
wrote:
> We also need a way to know which intrinsics are available for the current
> target. Currently clang accepts all of them and you get a “cannot select”
> error from the backend if the intrinsic is not available. We now have the
> mechanism to provide a better diagnostic from the backend, but clang will
do
> a better job of getting the source location right…. except that clang
> currently has no way to know details of the targets.
You know, thinking about named registers, Clang accepts any valid
register name for any target, so if you specify "eax" on ARM, clang
will happily let it go, to fail on the back-end, so maybe even
register names would be a valid thing to have available... I'm
wondering what shouldn't we put in this public library...

How big would this library end up? The size problem would only be a
problem on small devices, when running native (like Android
Renderscript or ARM JIT), since you don't *really* need all that bloat
from all other targets. If that's a real problem, wouldn't the value
of Clang being able to produce IR on all archs be overshadowed by it?

I mean, we have three issues:

1. It's nice to have Clang generate IR for all archs on any arch
2. We need target info to do that, currently Clang duplicates everything
3. We don't want to bloat native binaries in restricted environments

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?

cheers,
--renato

> I mean, we have three issues:
>
> 1. It's nice to have Clang generate IR for all archs on any arch
> 2. We need target info to do that, currently Clang duplicates everything
> 3. We don't want to bloat native binaries in restricted environments
>
> 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?
Last time the idea of just using lib/Target was raised Alp mentioning
having a use case for the current ability.

Cheers,
Rafael

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