[llvm-dev] Questions about relaxation in MC

[Konstantin Schwarz via llvm-dev]

Thanks for highlighting that patch!

Using instruction bundles indeed sounds interesting, as it seems more 
flexible. We'll see how far we get with this.

Konstantin

On 08.12.2020 16:10, Ryan Taylor wrote:
> We had a similar issue with a hardware bug where we changed the 32 bit 
> branch instruction encoding into a 64 encoding, the other 32 bit being 
> a NOP: 
> https://reviews.llvm.org/rG9ab812d4752b2a1442426db2ccc17dc95d12eb04 
> <https://reviews.llvm.org/rG9ab812d4752b2a1442426db2ccc17dc95d12eb04>
>
> We also looked at using a bundle instead of this encoding method as we 
> thought that might have been cleaner but that's a bit more complex, 
> not sure if either of these help you.
>
> On Tue, Dec 8, 2020 at 9:47 AM Konstantin Schwarz via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Hi Kai,
>
>     did you make any progress on this topic?
>     We have a similar case in our backend, where conditional branches
>     have only a limited range.
>     So for hand-written assembly, we would like to relax using the
>     scheme you describe: invert the branch condition and add an
>     unconditional jump.
>
>     As you've already discovered, the relaxInstruction callback
>     doesn't allow to insert additional instructions, but requires the
>     relaxed instruction to be returned.
>     We could work around that by relaxing to a pseudo instruction
>     whose size is the combined size of the conditional branch + jump
>     and expand it later to the actual instructions, but that seems
>     unnecessarily complex.
>
>     Did you come up with a better solution?
>
>     Konstantin
>
>     On 07.10.2020 17:20, Philip Reames via llvm-dev wrote:
>>
>>     If done in the assembler, this is branch relaxation.  You need to
>>     implement the calls backs mayNeedRelaxation, and relaxInstruction
>>     on your target MCAsmBackend.  The iteration relaxation logic
>>     already exists, see the generic MC code.
>>
>>     Philip
>>
>>     On 10/5/20 8:20 PM, Kai Wang via llvm-dev wrote:
>>>     Correct the title.
>>>
>>>     On Tue, Oct 6, 2020 at 11:11 AM Kai Wang <kai.wang at sifive.com
>>>     <mailto:kai.wang at sifive.com>> wrote:
>>>
>>>         Hi all,
>>>
>>>         In RISC-V ISA, the range of conditional branches is within
>>>         4KiB. In current implementation, if the branch target is out
>>>         of range, LLVM MC will issue an error message to tell users
>>>         it could not resolve the fixup record. I have compared the
>>>         result with the GNU assembler. GNU assembler will convert
>>>         the branch to inverted one plus jump to make the branch
>>>         possible. The range of unconditional jump is 1MiB. It looks like
>>>
>>>         ##########################
>>>         bne a0, a1, FAR_BRANCH
>>>         …
>>>         FAR_BRANCH:
>>>
>>>         converted to
>>>
>>>         ##########################
>>>         beq a0, a1, SKIP_J
>>>         j FAR_BRANCH
>>>         SKIP_J:
>>>         …
>>>         FAR_BRANCH:
>>>
>>>         I found there is a target hook, relaxInstruction, that tries
>>>         to achieve the similar goal. However, the target hook only
>>>         replaces one MCInst with another one with a larger branch
>>>         range. For example, c.beqz will be converted to beq in the
>>>         RISC-V backend if the fixup value is out of range. There
>>>         seems no target hook to convert one MCInst to a complex
>>>         pattern in LLVM MC. Do I miss something obvious?
>>>
>>>         I found there is a target hook, finishLayout, to manipulate
>>>         the code generated. Does it make sense to implement the
>>>         feature in finishLayout? Or is there any better idea to
>>>         achieve the conversion? Thanks a lot.
>>>
>>>         Best,
>>>         Kai
>>>
>>>
>>>     _______________________________________________
>>>     LLVM Developers mailing list
>>>     llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev  <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201210/e6276ddd/attachment.html>