[PATCH] D44971: [RISCV] Override fixupNeedsRelaxationAdvanced to avoid MC relaxation always promote to 32-bit form when -mrelax enabled

Alex Bradbury via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 5 03:51:50 PDT 2018


asb added inline comments.


================
Comment at: test/MC/RISCV/relocations.s:93
 
 c.jal foo
+# RELOC: R_RISCV_RVC_JUMP
----------------
sabuasal wrote:
> Hi Shiva,
> 
> 
> I noticed that gcc-as will relax jumps to unresolved symbols. only generates rvc-jump for resolved ones.
> 
> >echo  "c.jal foo" | riscv32-unknown-linux-gnu-as -march=rv32imc   -o ./a.out && riscv32-unknown-linux-gnu-objdump  -M no-aliases -dr ./a.out 
> >00000000 <.text>:
> >   0:   000000ef                jal     ra,0x0
> >                       0: R_RISCV_JAL  foo
> 
> >echo "foo: nop; jal foo" | riscv32-unknown-linux-gnu-as  -march rv32imc -o ./a.out && riscv32-unknown-linux-gnu-> objdump -d -r -M no-aliases ./a.out
> 
> >  0:   0001                    c.addi  zero,0
> >   2:   3ffd                    c.jal   0 <foo>
> >                        2: R_RISCV_RVC_JUMP     foo
> 
> We can still maintain this behavior by checking the "Fixup" kind and "resolved" in fixupNeedsRelaxationAdvanced.  However, this is a better code size optimization I think if the c.jal target appears to be within reach during linking.
> @asb 
> What do you think?
> 
> 
It would be great to expand the tests to cover the case of an unresolved jump target. Matching the gcc behaviour seems a sensible starting point.


Repository:
  rL LLVM

https://reviews.llvm.org/D44971





More information about the llvm-commits mailing list