[llvm-dev] Questions about relaxation in MC

Mon Feb 22 00:54:50 PST 2021

We could make this work using bundles in our backend, but needed to pass 
the MCContext to relaxInstruction to be able to allocate new 
instructions without leaking memory.

Could someone have a look at the patch (https://reviews.llvm.org/D95375)?

Konstantin

On 10.12.2020 13:34, Konstantin Schwarz wrote:
>
> 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>
>>
-- 
---------------------------------------------------------------------------
Konstantin Schwarz                Email: konstantin.schwarz at hightec-rt.com
HighTec EDV-Systeme GmbH          Phone: +49 681 92613 21
Europaallee 19
D-66113 Saarbrücken               WWW: http://www.hightec-rt.com

Managing Director: Vera Strothmann
Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient please notify the sender immediately
and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210222/79b84b9e/attachment.html>