[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