[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
  00000000 <.text>:
     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 mailing list