X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible.
It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals.
This TableGen backend replaces the tables by automatically generating them.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
68 ↗ | (On Diff #89991) | Why is this a vector and not just a static table of strings? Can you add a comment indicating what each of these corresponds to in VEX just so if someone is curious they easily find it? |
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
68 ↗ | (On Diff #89991) | Any table defined inside the class would require stating the size when defined (ExceptionList[11]), So I figured it's more maintainable this way. |
Removing the changed tests from this patch.
Another patch was uploaded including manual update of the EVEX2VEX tables and all the changed tests.
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
20 ↗ | (On Diff #90188) | I think LLVM coding standards say not to use iostream. |
21 ↗ | (On Diff #90188) | using namespace std is frowned upon in LLVM. Please use the std:: prefix explicitly where needed. |
84 ↗ | (On Diff #90188) | Can we use StringRef::startswith here? |
248 ↗ | (On Diff #90188) | This OpRec != OpRec2 check seems redundant due to the earlier check and continue. |
305 ↗ | (On Diff #90188) | You shouldn't need to call str(). getName() should return a StringRef that has an operator== |
309 ↗ | (On Diff #90188) | Should we skip EVEX_LL == 2 here? |
318 ↗ | (On Diff #90188) | I think this is calling std::find_if, but we should have an llvm::find_if that can take an object that supports with begin() and end() without needing to call them explicitly. So its two parameters instead of three. |
68 ↗ | (On Diff #89991) | Well from a quick look it seemed like some of them were just Q versions of similar instructions in VEX that have WIG right? Is there not some way we can detect that these have W==1 and infer that we shouldn't use a VEX WIG instruction? |
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
68 ↗ | (On Diff #89991) | If an instruction has WIG value, we map it to either W == 1 or W == 0 or both if they are available. |
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
81 ↗ | (On Diff #90298) | Make InstrStr a const std::string& right now there's a copy there. |
111 ↗ | (On Diff #90298) | What special about VPERMILPD that need to be manually added? Same question for the BROADCASTs. |
316 ↗ | (On Diff #90298) | How does this handle the MAX and MAXC instructions both having the same opcode information? |
utils/TableGen/X86EVEX2VEXTablesEmitter.cpp | ||
---|---|---|
111 ↗ | (On Diff #90298) | They do not accept on the W-bit. |
316 ↗ | (On Diff #90298) | As I said in the other patch, in this stage of the compiler, there is no difference between MAX and MAXC, so the first to match is picked. |