[PATCH] D121768: [X86][tablgen] Auto-generate trivial fields and trivial interfaces for target features

Kan Shengchen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 19 02:47:27 PDT 2022


skan added a comment.

In D121768#3393949 <https://reviews.llvm.org/D121768#3393949>, @skan wrote:

> In D121768#3393927 <https://reviews.llvm.org/D121768#3393927>, @skan wrote:
>
>> In D121768#3393916 <https://reviews.llvm.org/D121768#3393916>, @craig.topper wrote:
>>
>>> In D121768#3393915 <https://reviews.llvm.org/D121768#3393915>, @skan wrote:
>>>
>>>> In D121768#3393913 <https://reviews.llvm.org/D121768#3393913>, @craig.topper wrote:
>>>>
>>>>> So you want feature specific knobs that you have to pass through those front end command line interfaces with something like clang’s -mllvm?
>>>>>
>>>>> In my opinion we should add more interfaces  in X86TargetParser.cpp so that all frontends can learn what features llvm supports without a hardcoded list like in Options.td. And those frontends should use the target-feature attribute.
>>>>
>>>> Some front-ends are not open-source. We could not teach it.
>>>
>>> If we provide good library interfaces the non open source projects can implement it themselves.
>>>
>>> There’s no guarantee that a way to set an llvm override exists in another frontend. Last I knew ispc for example didn’t have an equivalent of -mllvm. I think I heard once that Apples version of clang doesn’t support -mllvm.
>>
>> We don't have such "good library interfaces" by now,  so we should keep the flexibility until that.  At least for now, we could not force a non open source front end to support that plugin.
>
> How about this case?

Never mind. I could do some work to enable somthing like "-mattr" when LTO is enabled in theory, so non-trivial getter is not necessary.

I have one last question for @RKSimon :

D120906 <https://reviews.llvm.org/D120906> drops comments in the header file by moving them to TD file. Is there any document issue due to this?

If there is, I think we should use tablgen to emit C++ bits directly rather than use macro to expand the code.
If it's not a issue, I'm tempted to abandon this pacth and do similar things for X86 like D120906 <https://reviews.llvm.org/D120906>.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121768/new/

https://reviews.llvm.org/D121768



More information about the llvm-commits mailing list