[PATCH] D59398: [X86] Remove the _alt forms of XOP VPCOM instructions. Use a combination of custom printing and custom parsing to achieve the same result and more

[Craig Topper via Phabricator via llvm-commits]

craig.topper created this revision.
craig.topper added reviewers: RKSimon, spatel.
Herald added subscribers: jdoerfert, lebedev.ri, gbedwell.
Herald added a reviewer: andreadb.
Herald added a reviewer: lebedev.ri.

Previously we had a regular form of the instruction used when the immediate was 0-7. And _alt form that allowed the full 8 bit immediate. Codegen would always use the 0-7 form since the immediate was always checked to be in range. Assembly parsing would use the 0-7 form when a mnemonic like vpcomtrueb was used. If the immediate was specified directly the _alt form was used. The disassembler would prefer to use the 0-7 form instruction when the immediate was in range and the _alt form otherwise. This way disassembly would print the most readable form when possible.

The assembly parsing for things like vpcomtrueb relied on splitting the mnemonic into 3 pieces. A "vpcom" prefix, an immediate representing the "true", and a suffix of "b". The tablegenerated printing code would similarly print a "vpcom" prefix, decode the immediate into a string, and then print "b".

The _alt form on the other hand parsed and printed like any other instruction with no specialness.

With this patch we drop to one form and solve the disassembly printing issue by doing custom printing when the immediate is 0-7. The parsing code has been tweaked to turn "vpcomtrueb" into "vpcomb" and then the immediate for the "true" is inserted either before or after the other operands depending on at&t or intel syntax.

I'd rather not do the custom printing, but I tried using an InstAlias for each possible mnemonic for all 8 immediates for all 16 combinations of element size, signedness, and memory/register. The code emitted into printAliasInstr ended up checking the number of operands, the register class of each operand, and the immediate for all 256 aliases. This was repeated for both the at&t and intel printer. Despite a lot of common checks between all of the aliases, when compiled with clang at least this commonality was not well optimized. Nor do all the checks seem necessary. Since I want to do a similar thing for vcmpps/pd/ss/sd which have 32 immediate values and 3 encoding flavors, 3 register sizes, etc. This didn't seem to scale well for clang binary size. So custom printing seemed a better trade off.

I also considered just using the InstAlias for the matching and not the printing. But that seemed like it would add a lot of extra rows to the matcher table. Especially given that the 32 immediates for vpcmpps have 46 strings associated with them.


https://reviews.llvm.org/D59398

Files:
  lib/Target/X86/AsmParser/X86AsmParser.cpp
  lib/Target/X86/Disassembler/X86Disassembler.cpp
  lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp
  lib/Target/X86/InstPrinter/X86ATTInstPrinter.h
  lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp
  lib/Target/X86/InstPrinter/X86IntelInstPrinter.h
  lib/Target/X86/X86InstrInfo.td
  lib/Target/X86/X86InstrXOP.td
  test/tools/llvm-mca/X86/BdVer2/resources-xop.s
  test/tools/llvm-mca/X86/Generic/resources-xop.s
  utils/TableGen/X86RecognizableInstr.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D59398.190752.patch
Type: text/x-patch
Size: 35141 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190315/25bb41be/attachment-0001.bin>