s390x: Emit 20bit immedate variants of indexed loads

[theotherjimmy]

Previously, cranelift did not emit memory operations using 20 bit immedates for reg + reg memory modes on s390x. This patch enables that in a type safe manner by exporting a few extractors for 20 bit immediates and changing the argument to the MemArg constructor for reg + reg addressing mode to accept that 20 bit offset instead of the u8 offset.

[github-actions]

Subscribe to Label Action

cc @cfallin, @fitzgen

Details

This issue or pull request has been labeled: "cranelift", "isle"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[cfallin]

cc @uweigand -- would you mind taking a look?

[uweigand]

Hi @theotherjimmy this makes sense in principle, but I have a couple of comments:

• The bias naming was intended to reflect small offset generated by the back-end to access part of a value (e.g. when accessing a 16-byte value as two 8-byte values, the second value needs to have the address biased by 8); it was not intended to act as a generic displacement. If we want that, we should probably rename the function to reg_plus_reg_plus_off or something.
• With your code, we're now greedily generating reg+reg+simm20 always, and retroactively fix things if the instruction doesn't have that addressing mode. That is probably the right thing to do in general, but in many cases we already know that the addressing mode isn't available (e.g. vector instructions always only have uimm12 displacements). We'll likely get better code if we leave the addition separately from the beginning in those cases.

[theotherjimmy]

Thanks for the review @uweigand

I think I'll rework this to write a new extractor with your suggested name, and migrate to that new extractor where we know the instructions support the extended offset. That should resolve your concerns.

[theotherjimmy]

@uweigand Is this more in line with what you expected?

[uweigand]

This looks generally good to me. As a small enhancement it might be interesting to also extend the lower_address_bias version with a memarg_reg_plus_reg_plus_off clause (which would add the bias to the offset); this probably doesn't have much effect on performance but would preserve the symmetry.

A much bigger (future) enhancement could be to be more specific in generating proper addressing modes for the target instruction in the first place:

• Avoid using the generic RegOffset mode but rather generate explicit code to begin with (e.g. along the lines of the AArch64 amode rules).
• Use more specific flavors of lower_address (e.g. lower_address_bdaddr12, lower_address_bdaddr20, lower_address_bdxaddr12, lower_address_bdxaddr20 to follow LLWM nomenclature) and update the various rules to use the specific flavors instead of the generic, as appropriate for the target instruction of each rule.

[uweigand]

This LGTM now, thanks!

[cfallin]

Thanks Ulrich for the review on this!