[llvm] r330826 - [RISCV] Support "call" pseudoinstruction in the MC layer

[Alex Bradbury via llvm-commits]

On 25 April 2018 at 15:18, Shiva Chen via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> Author: shiva
> Date: Wed Apr 25 07:18:55 2018
> New Revision: 330826
>
> URL: http://llvm.org/viewvc/llvm-project?rev=330826&view=rev
> Log:
> [RISCV] Support "call" pseudoinstruction in the MC layer
>
> To do this:
> 1. Add PseudoCALLIndirct to match indirect function call.
>
> 2. Add PseudoCALL to support parsing and print pseudo `call` in assembly
>
> 3. Expand PseudoCALL to the following form with R_RISCV_CALL relocation type
>    while encoding:
>         auipc ra, func
>         jalr ra, ra, 0
>
> If we expand PseudoCALL before emitting assembly, we will see auipc and jalr
> pair when compile with -S. It's hard for assembly parser to parsing this
> pair and identify it's semantic is function call and then insert R_RISCV_CALL
> relocation type. Although we could insert R_RISCV_PCREL_HI20 and
> R_RISCV_PCREL_LO12_I relocation types instead of R_RISCV_CALL.
> Due to RISCV relocation design, auipc and jalr pair only can relax to jal with
> R_RISCV_CALL + R_RISCV_RELAX relocation types.
>
> We expand PseudoCALL as late as encoding(RISCVMCCodeEmitter) instead of before
> emitting assembly(RISCVAsmPrinter) because we want to preserve call
> pseudoinstruction in assembly code. It's more readable and assembly parser
> could identify call assembly and insert R_RISCV_CALL relocation type.

I've found this patch has problems with function names that coincide
with register names. e.g. `call zero` or `call f0`. In combination
with r330827, this leads to compilation failures when -save-temps is
used.

Got to catch the bus right now, but I'll try and commit a fix very shortly.

Best,

Alex