Some EVEX instructions should check the predicates when compress to VEX
encoding. For example, avx512vnni instructions. This is because avx512vnni
doesn't mean that avxvnni is supported on the target.
This patch moving the manually added check to .inc that generated by tablegen.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86InstrFormats.td | ||
---|---|---|
356 | checkVEXPredicate? | |
llvm/lib/Target/X86/X86InstrSSE.td | ||
7169 | Should be simple to add here i.e. ExplicitVEXPrefix, checkPredicate = 1 | |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
23 | Can we assume the predicates that need to check all started with HasAVXxxx. Then we don't need such table. | |
44 | Do we really need 2 tables? | |
202 | If we can assume the predicates that need to check all started with HasAVXxxx, then we just need to find it in the PredicatesRecords and check it only. |
llvm/lib/Target/X86/X86InstrSSE.td | ||
---|---|---|
7203 | Do we support customized code for CheckPredicate, so that we can extend the functionality someday? In this case the CheckPredicate is {ST->hasAVXVNNI();}. |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
204 | releated -> related |
llvm/lib/Target/X86/X86InstrFormats.td | ||
---|---|---|
356 | Maybe in the future we need check more Predicate than VEX? | |
llvm/lib/Target/X86/X86InstrSSE.td | ||
7169 | Of course we can do this. | |
7203 | I think if you want to add customized check, you can add Predicate like "def HasAVXVNNI". Than this predicate can include in the table EVEX2VEX[128/256]Predicates. | |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
23 | Yes. It's good idea. | |
44 | You are right. We don't need 2 tables. |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
202 | Related to Yuanke's question, if support customized code for CheckPredicate, the name could be something else, so that we can't depend on the whether the predicate starts with "HasAVX". This is also my first thought. What's your opinion here? Of course we can apply your method firstly and added more conditions in the future. |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
202 | I'm not sure what's customized for in future. I can see its only required during this EVEX to VEX transformation. Any thoughts @LuoYuanke ? |
Thanks for your review, @lebedev.ri. This is actually one NFC patch. I think we don't need add new tests.
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
202 | I'm just thinking if the predict can be extensible. I agree we can apply current approach first and refactor it if any extension is needed. |
llvm/lib/Target/X86/X86InstrSSE.td | ||
---|---|---|
7169 | I am sorry that I forgot this! |
llvm/lib/Target/X86/X86EvexToVex.cpp | ||
---|---|---|
255–259 | Don't need to reformat the unrelated code. | |
llvm/lib/Target/X86/X86InstrFormats.td | ||
239 | This is not needed. | |
356 | I think you can add VEX for now since you mentioned on the comment too. | |
llvm/lib/Target/X86/X86InstrSSE.td | ||
7203–7206 | These are not needed. | |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
206–207 | Do you have cases that have more than one HasAVXxxx in Predicates? | |
209 | Not necessary? | |
213–214 | We don't need to add case XXX return ture since we use the default: return true;. |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
213–214 | Yes. The default value should be 'llvm_unreachable'. In this case, "return true" is needed. |
LGTM.
llvm/lib/Target/X86/X86InstrFormats.td | ||
---|---|---|
356 | Nit: Not a good sentences. How about: | |
llvm/utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
58 | Nit: Add comments like above. | |
202 | Nit: Maybe bettter to move the comments above the for or add curly brackets for for. |
I think @LiuChen3 's NFC firstly means to LLVM. I.e. Moving the manually added check to .inc that generated by tablegen. It's hard to say NFC for the tablegen code. But with a coarse search, I didn't find we have a test for this EVEX2VEX backend. So I assumed it is covered by LLVM tests. By this mean, I think we can call it a NFC :)
Don't need to reformat the unrelated code.