The decoding parts are reduplicative, we add a macro to simplify
the code.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp | ||
---|---|---|
493 | Typo: FEATURE everywhere |
The order we search these tables doesn't make sense. Shouldn't we be checking the standard table first, then falling back to vendor tables after that? Even with a vendor extension enabled, the majority of the instructions are going to be standard so we should decode them first.
Downstream we have a separate encoding mode that replaces some standard instructions with alternative ones; even if the order doesn't matter upstream, it would be preferable for us if the standard table was the last one not the first one.
I didn't change the order, it is the same. Does the order really matter? The vendor extensions must not conflict with standard encoding space.
But from the perspective of compile time, I think the order may matter because for most instructions they can exit the decoding early.
Does the replacement happen in decoding not encoding? Just curious about the functionality of such replacement.
Well my thought doesn't work anyway because Zcmp and Zcmt are in a separate decoder namespace but the instructions they replace from C aren't in a namespace. So they have to be checked first. Same with Zfinx/Zdinx vs F/D.
Or maybe the predicate check in the DecoderTable fixes that?
Anyway it doesn't affect this patch just an observation to think about.
Hm, actually, shouldn't the predicates on the instructions themselves make it all work, both our case downstream and the Zcm*+Z*inx cases?
Typo: FEATURE everywhere