[llvm-dev] Branch relaxation at assembler level (RISCV)

[Friedman, Eli via llvm-dev]

On 12/4/2018 4:56 PM, Bruce Hoult wrote:
> On Tue, Dec 4, 2018 at 12:13 PM Friedman, Eli via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On 12/3/2018 2:45 PM, Paolo via llvm-dev wrote:
>     > Hi all,
>     >
>     > I'm trying to implement the same branch relaxation mechanism
>     implemented
>     > in CodeGen in the MC layer of RISCV.
>     >
>     >    beqz t1, L1
>     >
>     >    =>
>     >
>     >    bnez t1, L2
>     >
>     >    j L1
>     >
>     > That's because LLVM does not apply the CodeGen optimizations when
>     > compiling directly from assembly code.
>     >
>     > What I'd like to do would be to add a pass that does that on the MC
>     > instructions or at least to find a way to implement this
>     relaxation in
>     > the MC assembler.
>     >
>     > Any suggestions on where/how to do it? Or any existing fixes?
>
>     The RISCV assembler already has code for similar transforms; see
>     RISCVAsmBackend::mayNeedRelaxation and
>     RISCVAsmBackend::relaxInstruction.  The only tricky bit is that the
>     relaxation interface doesn't expect one instruction to be relaxed
>     to two
>     instructions... probably not too hard to change, though, if necessary.
>
>
> Note that it is *extremely* important that RISC-V relaxations only 
> ever make the code shorter, never longer.
>
> If the instructions stay the same size, it can not be permitted to 
> replace one instruction with two.
>
> Changing a 32 bit instruction to two 16 bit instructions could be ok, 
> but I'm struggling to think of an example when that would be beneficial.

We're talking about assembler "relaxations" (basically, the assembler 
trying to resolve an ambiguous branch instruction), not RISCV linker 
relaxations.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/2510ecc0/attachment.html>