[PATCH] D143471: [X86][MC][NFC] Refine code in X86MCCodeEmitter.cpp about opcode prefix

Kan Shengchen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 8 22:13:01 PST 2023


skan added a comment.

In D143471#4114625 <https://reviews.llvm.org/D143471#4114625>, @craig.topper wrote:

> Thinking....  What if we took this further and had an "encodeable instruction" object that contains the prefix fields and the modrm fields that we build by walking the operands and format once. Then we would only have 1 switch on format instead of the 3 we have now. Then we use that to emit the prefix, the opcode, and the modrm byte.

This sounds good! Let me give a try.



================
Comment at: llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:140
+  void setR(const MCInst &MI, unsigned OpNum) {
+    R = MRI.getEncodingValue(MI.getOperand(OpNum).getReg()) >> 3 & 1;
+  }
----------------
craig.topper wrote:
> I'm not sure if it makes sense to have this class understand MRI and MI. I kind of think it should only receive the register encoding.
> 
> Especially when you look at funcions like setRR2 that now end up looking up the encoding twice because it nests calls to setR and setR2.
I agree the name `X86OpcodePrefix` doesn't sound like much to understand MI, we should have a "Helper" suffix.

Encoding twice is not a big issue. We can easily extract a function "getX86RegEncoding" to avoid this.

I am thinking your new proposal "encodeable instruction" 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143471



More information about the llvm-commits mailing list