[PATCH] D41949: [RISCV] implement li pseudo instruction
Mario Werner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Feb 16 02:35:18 PST 2018
niosHD added a comment.
I just stumbled across a difference between the binutils assembler and my current `li` implementation regarding accepted immediate values.
The following snippet shows the issue:
% cat li.S
li t0, 0x80000000
li t1, -2147483648
li t2, 3147483648
li t3, -3147483648
% riscv32-unknown-elf-gcc -o li.o -c li.S && riscv32-unknown-elf-objdump -d li.o
0: 800002b7 lui t0,0x80000
4: 80000337 lui t1,0x80000
8: bb9ad3b7 lui t2,0xbb9ad
c: a0038393 addi t2,t2,-1536 # 0xbb9aca00
10: 44653e37 lui t3,0x44653
14: 600e0e13 addi t3,t3,1536 # 0x44653600
While it may be reasonable to accept the first three `li` instructions, accepting the fourth one definitely does not feel correct. It looks to me as if the immediate verification of the binutils assembler accepts everything that can theoretically be represented as 32-bit value, potentially even as purely negative number. My current implementation verifies that the immediate is a 32-bit signed integer and therefore only accepts the second `li` instruction in the above example. Should we also be more relaxed regarding immediate verification or should this be considered as binutils bug?
More information about the llvm-commits