CPU features handling

Hi,

Clang currently maintains its own knowledge of cpu features. See
clang/lib/Basic/Targets.cpp:getDefaultFeatures() and setFeatureEnabled().

This knowledge is already and better maintained in Target specific .td
files (e.g. Target/X86/X86.td).

I would like to make clang use the information provided by llvm, the question
is how. I think that the best would be to let clang see FeatureKV[] and
SubTypeKV[] from *GenSubtarget.inc (e.g. Target/X86/X86GenSubtarget.inc).

I am not sure how to do it though. Can you comment on what you think is
the best way to tackle this? We cant link libclangBasic to libLLVMTarget
and it seems strange to copy the *GenSubtarget.inc to libBasic. I cant
think of any other solution

thank you

Roman

Hi Roman,

Hi,

Clang currently maintains its own knowledge of cpu features. See
clang/lib/Basic/Targets.cpp:getDefaultFeatures() and setFeatureEnabled().

Yes. This is really ugly (and my fault), but at the time was the most
expedient thing.

This knowledge is already and better maintained in Target specific .td
files (e.g. Target/X86/X86.td).

Yes.

I would like to make clang use the information provided by llvm, the question
is how. I think that the best would be to let clang see FeatureKV[] and
SubTypeKV[] from *GenSubtarget.inc (e.g. Target/X86/X86GenSubtarget.inc).

I am not sure how to do it though. Can you comment on what you think is
the best way to tackle this? We cant link libclangBasic to libLLVMTarget
and it seems strange to copy the *GenSubtarget.inc to libBasic. I cant
think of any other solution

There are two basic approaches. It's been a while since I looked at
this, so I forget enough details to know which one we should pursue.

The first approach is to extend the target interface so that client's
of LLVM can interrogate the target. This should be much easier to add
now that we have the target registry. One downside is it means we
would be linking in more code, but the work on the target registry
means that in theory clients can only link in the "target info" and
not the entire code generator. Theory != practice, currently. Also,
once we merge clang-cc into clang we will link in everything anyway so
this is less of a concern.

The other approach is that we have a tablegen backend which converts
the target feature information into separate .inc files which we would
use in clang. The benefit of this approach is that we can massage the
data into whatever format we want.

- Daniel

> I am not sure how to do it though. Can you comment on what you think is
> the best way to tackle this? We cant link libclangBasic to libLLVMTarget
> and it seems strange to copy the *GenSubtarget.inc to libBasic. I cant
> think of any other solution

There are two basic approaches. It's been a while since I looked at
this, so I forget enough details to know which one we should pursue.

The first approach is to extend the target interface so that client's
of LLVM can interrogate the target. This should be much easier to add
now that we have the target registry. One downside is it means we
would be linking in more code, but the work on the target registry
means that in theory clients can only link in the "target info" and
not the entire code generator. Theory != practice, currently. Also,
once we merge clang-cc into clang we will link in everything anyway so
this is less of a concern.

The other approach is that we have a tablegen backend which converts
the target feature information into separate .inc files which we would
use in clang. The benefit of this approach is that we can massage the
data into whatever format we want.

I'll go the latter way. I'll modify tblgen to create subtarget features,
ie. FeatureKV[] and SubTypeKV[] and I'll use that to derive the information
we need.

I am not sure how to write the makefile rules though... I'll see what I'll get
and present it here for further comments