[llvm-dev] [RISCV][PIC] Lowering pseudo instructions in MCCodeEmitter vs AsmPrinter

[Roger Ferrer Ibáñez via llvm-dev]

H all,

I'm looking at generating PIC code for RISC-V in the context of Linux. Not
sure if anyone is working on this already, any inputs are very welcome.

I'm now looking at function calls which in the RISCV backend are
represented via two pseudoinstructions RISCV::TAIL and RISCV::CALL.

Currently those pseudos are lowered in MCCodeEmitter. They are expanded
into AUIPC and JALR instructions and the first one needs a relocation,
which for a static reloc model is R_RISCV_CALL but for PIC code should be
R_RISCV_CALL_PLT.

The problem I find is that at this point it is too late to tell the exact
relocation needed: as far as I can tell there is no way to determine the
relocation model. Perhaps this is on purpose and the MCCodeEmitter should
not have that knowledge. Or maybe not and it is just a matter to "push" a
TargetMachine to it, but the way the class is constructed does not look
like this approach is workable.

So I was considering lowering these pseudo-instructions in AsmPrinter
instead. There I can tell the exact kind of the MCOperand I want thanks to
the fact that the AsmPrinter is constructed with a TargetMachine.

That said perhaps there are extra constraints that require doing the
lowering in MCCodeEmitter, unfortunately I can't tell exactly what is the
advantage of lowering that late.

These pseudos are marked as isCodegenOnly = 0 so if I lower them in
AsmPrinter my understanding is that now I have to change them to
isCodegenOnly = 1 and then teach AsmParser to recognize them (I would need
to use the reloc model there too). Does this make sense?

Alternatively I was considering adding two new pseudos like RISCV::CALL_PLT
and RISCV::TAIL_PLT and also lower them at MCCodeEmitter. But this looks a
bit too bulky to me and I think I would still have the issue that the
"call" and "tail" pseudos in the assembler would need some extra magic
(i.e. when assembling a "call" pseudoinstruction with -fPIC) so they don't
end being parsed as the non-PIC counterparts. I might be wrong here though.

Is this reasonable or there are other downsides to consider here?

Thank you very much,

-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180710/cbf1c638/attachment.html>