This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] For rv32, accept constants like 0xfffff800 as a valid simm12.
ClosedPublic

Authored by craig.topper on Feb 16 2023, 12:35 AM.

Details

Summary

Internally we store constants in int64_t after parsing, but this is
kind of an implementation detail. If we only supported rv32, we might
have chosen int32_t.

For rv32, I think it makes sense to accept the constants that we
would accept if int32_t was the internal type. In fact we already
do this for the li alias. This patch extends this to sign
extended constants for other instructions.

This matches the GNU assembler. The difference between LLVM and gcc
was previously noted here. https://github.com/riscv-non-isa/riscv-asm-manual/pull/71

Diff Detail

Event Timeline

craig.topper created this revision.Feb 16 2023, 12:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 16 2023, 12:35 AM
craig.topper requested review of this revision.Feb 16 2023, 12:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 16 2023, 12:35 AM

The reasoning and approach makes sense to me. I haven't (yet) checked the implementation and test coverage in detail, so this is a weak approval only.

llvm/test/MC/RISCV/rv32i-only-valid.s
10

Please add a comment with the hex representation. Personally, I can't eyeball these large ones and be sure it's exactly 0xFFFFFFFF.

Rename function.
Add comment to test.

Basic idea makes complete sense to me. One question on implementation.

llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
772

Is this checking the right thing? It seems like maybe we want to allow the 32 bit form on the Imm -1, not the Imm. Main case I'm thinking of is what if imm is smin<5> and thus smin<5>-1 is not an int<5>.

Alternatively said, please check what gcc does and make sure our behavior matches in the edge case.

craig.topper added inline comments.Feb 17 2023, 8:20 AM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
772

I think it's right. Imm is the value written by the user. If I sign extend after subtracting 1 we will accept 0x100000000 the same as if the user had written 0. Because 0x100000000 will be decremented to 0xffffffff which will sign extend to 0xffffffffffffffff. We also get 0xffffffffffffffff from subtracting 1 from 0.

The valid input values should be the ranges [-15, 16] and [0xfffffff1, 0xffffffff].

reames accepted this revision.Feb 17 2023, 8:57 AM

LGTM

This revision is now accepted and ready to land.Feb 17 2023, 8:57 AM
This revision was landed with ongoing or failed builds.Feb 17 2023, 10:54 AM
This revision was automatically updated to reflect the committed changes.

I suppose we could also have added S-type instructions tests, for thoroughness.