(original) (raw)
Hi,
This discussion caught my eye because
we are also looking at a very similar problem on PowerPC.
We have a situation where we want to
align a given instruction to a 64 byte boundary. If it's not already aligned
we just add nops until it is aligned (We plan to do this in a custom PPCStreamer).
If the branch and the target of that branch are far enough away adding
a few nops in-between may actually overflow the 14 bits we have to represent
the offset in the branch instruction and in that case we have to do something
special and replace the branch with something else that, once again, is
not a single instruction.
If mayNeedRelaxation and relaxInstruction are not the way to do this is there any other
better way?
Thanks,
Stefan
From:
"Friedman, Eli
via llvm-dev" llvm-dev@lists.llvm.org
To:
Paolo paolo.savini@embecosm.com,
llvm-dev@lists.llvm.org
Date:
2018/12/04 03:15 PM
Subject:
Re: [llvm-dev]
Branch relaxation at assembler level (RISCV)
Sent by:
"llvm-dev"
llvm-dev-bounces@lists.llvm.org
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.
That said, I'm a little skeptical this is actually a good idea; the more
"smart" the assembler is, the harder it becomes to understand
what it's
doing. No other in-tree target does this sort of transform.
-Eli
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev