[LLVMdev] Target specific info available to Clang (and others) (original) (raw)

Renato Golin renato.golin at linaro.org
Fri Oct 24 10:17:41 PDT 2014

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

More information about the llvm-dev mailing list