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

[Rafael Avila de Espindola]

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/cfe-dev/attachments/20141024/9c830156/attachment.html>