[llvm-dev] Questions about relaxation in MC
Kai Wang via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 10 08:42:01 PST 2020
Hi Ryan,
Thanks for your information. I will check it out.
On Thu, Dec 10, 2020 at 11:20 PM Ryan Taylor <ryta1203 at gmail.com> wrote:
> You should check Hexagon, it appears that they use bundles with relaxation.
>
> On Thu, Dec 10, 2020 at 9:21 AM Kai Wang via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Konstantin,
>>
>> No, I have no progress in this issue. After discussing in the RISC-V
>> sync-up meeting, I filed a bug in the LLVM bugzilla.
>> https://bugs.llvm.org/show_bug.cgi?id=47910
>>
>>
>> On Tue, Dec 8, 2020 at 10:46 PM Konstantin Schwarz <
>> konstantin.schwarz at hightec-rt.com> 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> 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 listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 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/20201211/c5030074/attachment.html>
More information about the llvm-dev
mailing list