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

Bob Wilson bob.wilson at apple.com
Fri Oct 24 09:48:35 PDT 2014

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

More information about the llvm-dev mailing list