-
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
Generate more fixed_nonallocatable constraints, and add debug assertions #5132
Generate more fixed_nonallocatable constraints, and add debug assertions #5132
Conversation
92bc735
to
463b859
Compare
Subscribe to Label Action
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "isle"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
463b859
to
e2221c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thought on s390x's EmitInfo
below, but general direction seems OK.
Separately from these asserts, we were also going to add checks that we don't use any pinned vregs, right? So the vreg provided to any operand (normal use/def, fixed-constraint use/def) needs to be non-pinned, i.e. >= 128.
e2221c2
to
528e71e
Compare
f05681c
to
b085ce4
Compare
664ffb5
to
bf21a10
Compare
bf21a10
to
b6aa575
Compare
b6aa575
to
52a14a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
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.
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 now 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.
Consumption of non-allocatable operands was added in bytecodealliance#5253 and bytecodealliance#5132, and removed in bytecodealliance#8524 and following PRs. Now they are not only ignored by regalloc2, but the placeholders that it leaves in the allocation results are also ignored by Cranelift. So let's stop adding them to the operands list entirely.
Consumption of non-allocatable operands was added in #5253 and #5132, and removed in #8524 and following PRs. Now they are not only ignored by regalloc2, but the placeholders that it leaves in the allocation results are also ignored by Cranelift. So let's stop adding them to the operands list entirely.
Add assertions to the
OperandCollector
that show we're not using pinned vregs, and usereg_fixed_nonallocatable
constraints when a real register is used with other constraint generation functions likereg_use
etc.I experimented with adding debug assertions that the reused operand referenced in
reg_reuse_def
constraints was compatible with the new constraint that would be generated. This didn't end up being possible as some backends will recursively process instructions when collecting operands, making it impossible without more invasive changes to tell where that operand is in the operand vector. Given that we would need to plumb through somewhat substantial changes to support adding debug assertions, I decided that rephrasing the existing warning comment about real registers would be good enough.