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.