This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][NFC] Simplify decoding code of disassembler
ClosedPublic

Authored by pcwang-thead on May 24 2023, 1:59 AM.

Details

Summary

The decoding parts are reduplicative, we add a macro to simplify
the code.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 24 2023, 1:59 AM
pcwang-thead requested review of this revision.May 24 2023, 1:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 24 2023, 1:59 AM

Remove extra space and colon.

kito-cheng accepted this revision.May 24 2023, 2:26 AM

LGTM, great simplify!

This revision is now accepted and ready to land.May 24 2023, 2:26 AM

Rename DBG_MSG to DESC.

kito-cheng accepted this revision.May 24 2023, 7:37 PM

still lgtm

jrtc27 added inline comments.May 24 2023, 7:47 PM
llvm/lib/Target/RISCV/Disassembler/RISCVDisassembler.cpp
493

Typo: FEATURE everywhere

pcwang-thead marked an inline comment as done.May 24 2023, 8:00 PM

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.

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.

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.

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.

Does the replacement happen in decoding not encoding? Just curious about the functionality of such replacement.

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.

Does the replacement happen in decoding not encoding? Just curious about the functionality of such replacement.

Both directions need to be consistent...

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.

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.

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.

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.

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.

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.

Hm, actually, shouldn't the predicates on the instructions themselves make it all work, both our case downstream and the Zcm*+Z*inx cases?

Simplify decoding with addtional operation (e.g. add SP operand).