transparent long branches

[neumannt]

Conditional branches can only jump of to 1MB, which can be a problem for large generated code. xbyak could handle that transparently by branching to an unconditional branch instruction if needed, which can then breach 128MB.

We have a need for supporting large generated code and could contribute a patch. Would you be willing to accept such functionality? If yes, do you have any suggestions how to integrate that into the code base?

Our plan would be to patch the LabelManager to check the distances, and if a label is unreachable we would create a branch to a (pending) thunk instruction that then jumps unconditionally. These instructions would be emitted at the next convenient moment, e.g., after the next unconditional branch. In the unlikely event that there is no unconditional branch anywhere within 1MB of the original branch we would have to insert one, but that should never happen in reality.

The advantage of fixing this problem in xbyak instead of in the application is that xbyak can keep track of pending distances, which is not easily possible in the application itself.

[herumi]

Hi @neumannt, thank you for the suggestion.

@kawakami-k
Would you mind sharing the following method?

If farLabel is too long, then

  ja(farLabel);

generates

  ja(nearL);
  b(nextL);
L(nearL);
  b(farLabel);
L(nextL);

.
This way may be a bit redundant but I think it will work anytime.
If it is okay, I'll try to implement it.

[neumannt]

One difficulty here is that you might not have seen farLabel yet, thus you cannot know that it is too far away. To handle that the LabelManager has to remember what his "oldest" pending label is, and if that is getting too far away you insert a sequence similar to what you have shown, issuing unconditional branches. Which are still pending, but can now reach a longer distance.

[herumi]

Sorry, I intended for the previous farLabel to be defined before use (backward references).

Label farLabel;
L(farLabel);
// huge code

ja(farLabel);

If farLabel may be a long jump, then specify it with T_FAR, which is used in the original Xbyak.

Label farLabel;
ja(farLabel, T_FAR); // forward references

// huge code
L(farLabel);

If T_FAR is specified, the previous code in my comment will be generated.
If T_FAR is specified but the jump is small, the generated code is redundant.
If a forward-referenced label is used without T_FAR and it turns out to be a huge jump, an exception will be thrown as before.
With this specification, the changes to Xbyak_aarch64 can be kept minimal.

[neumannt]

But using T_FAR pessimizes the generated code for something that rarely happens. I think it is better to generate jump thunks on demand instead of always generating them. I can try to write a prototype implementation to show you what I mean. It should not affect the current Xbyak_aarch64 interface, everything is internal.

[kawakami-k]

@neumannt
Thank you for the suggestion. It's good that the label manager can generate long jump instruction and accompanying conditional branch ones considering jump distance. We're willing to accept patches if you post!

@herumi
Do you plan to implement that feature?

[herumi]

@neumannt , I see. Could you make a pull request for the feature? We'll check it.