[all-commits] [llvm/llvm-project] 2ed0aa: [TableGen] Fixes for per-HwMode decoding problem (...

[Jason Eckhardt via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2ed0aacf973d628d5abae79229e251e034831dd3
      https://github.com/llvm/llvm-project/commit/2ed0aacf973d628d5abae79229e251e034831dd3
  Author: Jason Eckhardt <jeckhardt at nvidia.com>
  Date:   2024-02-19 (Mon, 19 Feb 2024)

  Changed paths:
    M llvm/test/TableGen/HwModeEncodeDecode.td
    M llvm/utils/TableGen/DecoderEmitter.cpp

  Log Message:
  -----------
  [TableGen] Fixes for per-HwMode decoding problem (#82201)

Today, if any instruction uses EncodingInfos/EncodingByHwMode to
override the default encoding, the opcode field of the decoder table is
generated incorrectly. This causes failed disassemblies and other
problems.

Specifically, the main correctness issue is that the EncodingID is
inadvertently stored in the table rather than the actual opcode. This is
caused by having set up the IndexOfInstruction map incorrectly during
the loop to populate NumberedEncodings-- which is then propagated around
when OpcMap is set up with a bad EncodingIDAndOpcode.

Instead, do away with IndexOfInstruction altogether and use opcode value
queried from CodeGenTarget::getInstrIntValue to set up OpcMap. This
itself exposed another problem where emitTable was using the decoded
opcode to index into NumberedEncodings. Instead pass in the
EncodingIDAndOpcode vector, and create the reverse mapping from Opcode
to EncodingID, which is then used to index NumberedEncodings.

This problem is not currently exposed upstream since no in-tree targets
yet use the per-HwMode feature. It does show up in at least two
downstream targets.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications