[llvm-dev] [MC] Questions about relaxation in MC

[Kai Wang via llvm-dev]

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

[Kai Wang via llvm-dev]

Correct the title.

[Hal Finkel via llvm-dev]

This sounds very similar to what PowerPC does, see: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp

However, PowerPC is doing this in the compiler backend, not in the assembler. One issue is that the process must be iterative, because branches can go both forward and backward, and replacing some branch instructions with the branch pairs can then cause other branches to go out of range.

 -Hal

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

[Anton Korobeynikov via llvm-dev]

And... MSP430 has the similar code :)

--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

[Kai Wang via llvm-dev]

Hi Hal,

Thanks for your information. If the input source is assembly code, is there any chance to do the similar thing? MC assembler seems to scan the assembly code one by one and convert them to MCInsts. Then do the assembler work, i.e., put MCInsts into fragments, generate fixups if needed, relaxation, code emission, etc.

 -Kai

[Kai Wang via llvm-dev]

Hi Anton,

Thanks for your information. I will look into MSP430.

 -Kai

[Philip Reames via llvm-dev]

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

[Konstantin Schwarz via llvm-dev]

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

[Ryan Taylor via llvm-dev]

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

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.

[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

[Kai Wang via llvm-dev]

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

[Ryan Taylor via llvm-dev]

You should check Hexagon, it appears that they use bundles with relaxation.

[Kai Wang via llvm-dev]

Hi Ryan,

Thanks for your information. I will check it out.

[Konstantin Schwarz via llvm-dev]

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

-- 
---------------------------------------------------------------------------
Konstantin Schwarz                Email: konstanti...@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.
---