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

[Renato Golin]

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