[llvm] [MC][TableGen] Pack MCInstrDesc fields into 24 bytes (PR #202647)
Momchil Velikov via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 12 09:13:01 PDT 2026
================
@@ -203,23 +204,40 @@ class MCInstrDesc {
// the <Target>Insts table because they rely on knowing their own address to
// find other information elsewhere in the same table.
- uint32_t Opcode; // The opcode number.
- uint16_t NumOperands; // Num of args (may be more if variable_ops)
- uint8_t NumDefs; // Num of args that are definitions
- uint8_t Size; // Number of bytes in encoding.
- uint16_t SchedClass; // enum identifying instr sched class
- uint8_t NumImplicitUses; // Num of regs implicitly used
- uint8_t NumImplicitDefs; // Num of regs implicitly defined
- uint16_t OpInfoOffset; // Offset to info about operands
- uint16_t ImplicitOffset; // Offset to start of implicit op list
- uint64_t Flags; // Flags identifying machine instr class
- uint64_t TSFlags; // Target Specific Flag values
+ uint64_t TSFlags; // Target-specific flag values.
+ uint64_t Flags : 41; // Flags identifying machine instruction classes.
----------------
momchil-velikov wrote:
What is the rationale behind choosing exactly these bit-field widths?
In some cases the possible range drastically shrinks, are we sure the remaining range is big enough today and will be big enough in the future?
Are there compile time results from the compile-time-tracker?
https://github.com/llvm/llvm-project/pull/202647
More information about the llvm-commits
mailing list