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

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?

cheers,
--renato

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.

Cheers,
Rafael

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