-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
s390x: Hard code the link register in all call and return instructions #9361
base: main
Are you sure you want to change the base?
Conversation
This matches the riscv64 backend.
cc @uweigand -- this looks reasonable to me overall, and there's no functional change to the emitted code or the regalloc metadata (fields were only ever used with one value) -- but maybe there's a reason it was generic? |
Well, as long as the ELF ABI is the only s390x ABI supported by wasmtime, I guess it doesn't make any difference, really. That said, this seems a step in the wrong direction to me: there are other ABIs used by other OSes on the platforms, and they do use different registers than r14 as the link register, so I'm not sure why it's an improvement to hard-code that value? Logically, it is an ABI property, that's why I placed that choice in ABI code rather than ISA code. |
The ret instruction is also hard coding r15 (stack pointer?) and it has a debug assert that r14 is used as link register. What other OSes use a different link register? |
Ah, not really. This instruction uses a condition mask field as "R1", not an actual register field, and the contents are 15 (all mask bits set) to indicate a "branch on any condition", i.e. an unconditional branch. It would have been clearer to add a variant of the
Huh, I'm surprised to see that. Looks like @elliottt added a bunch of asserts here: #5172 - I'm not sure if there's anything in that diff that makes those asserts necessary?
Well, XPLINK (the current main calling convention on z/OS) uses %r4, as one major example. In general, I'm pretty sure in case we ever wanted to support a significantly different calling convention like XPLINK that uses different registers for the link register, the stack register, and pretty much any ABI-defined register, we will find places where the current code isn't fully generalized. I tried to keep things general where it seemed easily possible, but didn't attempt any full review ... I just don't see why it's beneficial now to make the code less general. |
I think you're right, we should probably remove them. They're added in other cases to check that fixed constraints are respected, but as there's no fixed constraints in the constraint generation code in mod.rs, I don't think that assertion applies. |
This matches the riscv64 arch which also has the link register defined only by the abi and not by the isa itself. Also remove a couple of dead_code allows.