Skip to content
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

cranelift/s390x: Use PRegs consistently #8449

Merged
merged 1 commit into from
Apr 23, 2024

Conversation

jameysharp
Copy link
Contributor

@jameysharp jameysharp commented Apr 23, 2024

When OperandCollector's reg_use/reg_late_use/reg_def/reg_early_def methods are handed a Reg that refers to a physical ("real") register, they all delegate to reg_fixed_nonallocatable, ignoring the constraint kinds and positions. This behavior was introduced in #5132.

In several cases, the s390x backend was calling those methods with the result of the gpr or writable_gpr functions, which return physical registers. In these cases we can be more explicit that this is a non-allocatable register.

In addition, this PR reverts #4973 and #5121 because they became unecessary due, again, to #5132.

This doesn't change any behavior but is a nice change to split out of a larger PR I'm working on.

cc: @uweigand

@jameysharp jameysharp requested a review from a team as a code owner April 23, 2024 21:17
@jameysharp jameysharp requested review from cfallin and removed request for a team April 23, 2024 21:17
When OperandCollector's reg_use/reg_late_use/reg_def/reg_early_def
methods are handed a Reg that refers to a physical ("real") register,
they all delegate to reg_fixed_nonallocatable, ignoring the constraint
kinds and positions. This behavior was introduced in bytecodealliance#5132.

In several cases, the s390x backend was calling those methods with the
result of the `gpr` or `writable_gpr` functions, which return physical
registers. In these cases we can now be more explicit that this is a
non-allocatable register.

In addition, this PR reverts bytecodealliance#4973 and bytecodealliance#5121 because they became
unecessary due, again, to bytecodealliance#5132.
@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label Apr 23, 2024
Copy link
Member

@cfallin cfallin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@jameysharp jameysharp added this pull request to the merge queue Apr 23, 2024
Merged via the queue into bytecodealliance:main with commit 95fd37c Apr 23, 2024
21 checks passed
@jameysharp jameysharp deleted the s390-pregs branch April 23, 2024 22:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants