asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target#91643
asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target#91643bors merged 2 commits intorust-lang:masterfrom
Conversation
|
Thanks for putting this together! I had meant to reply to your comment on my PR, but it kept slippiing my mind. I'm not familiar with rustc internals at all, so I'm glad you have a solution to the circular dependency problem I ran into. |
|
☔ The latest upstream changes (presumably #91692) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
This is a little light on the explanation.
- How can I, as a user, "be careful" against register aliasing?
- If a reserved register is allocated into my registers how can I test for that? How can I fix it from happening again?
There was a problem hiding this comment.
I suppose the wording here is bad. What I meant to say is that reg may sometimes allocate the frame/base pointer register, even though it is not possible to allocate this register explicitly with "rbp".
There was a problem hiding this comment.
| In some cases LLVM will allocate a "reserved register" for `reg` operands even though this register cannot be explicitly specified. Assembly code making use of reserved registers should be careful since `reg` operands may alias with those registers. Reserved registers that can sometimes be allocated are the frame pointer and base pointer in the list above. | |
| While `asm!` statements cannot explicitly specify the use of reserved registers (such as frame pointer and base pointer registers), in some cases LLVM will allocate one of these reserved registers for `reg` operands. Assembly code making use of reserved registers should be careful since `reg` operands may use the same registers. |
There was a problem hiding this comment.
That answers one question, but I still don't understand the following:
- If I type a register class, such as
reg, can that give me a register LLVM considers reserved. - If so, is that a problem, or will LLVM sort it out somehow?
- If LLVM doesn't hand that on its own, what is the mitigation that an end programmer can put in their code?
edit: To be clear, I think the answer that Amanieu gave points to it possibly happening but it not being a problem, but the docs themselves should be very clear about whatever the situation is.
There was a problem hiding this comment.
So what is actually happening here is that in LLVM the frame pointer and base pointer registers are only marked as reserved if the function requires a frame/base pointer. If a register is not reserved then it may be selected by the register allocator.
In rustc we can't know in advance whether a function will require a frame/base pointer so we always disallow specifying the frame/base pointer as an explicit register. However it could still be selected for reg if the function doesn't need a frame/base pointer.
the current target.
|
I've removed the unstable book changes since that file is going to be deleted by #91728. I'm going to continue working on the wording for reserved registers in rust-lang/reference#1105. |
|
@bors r+ |
|
📌 Commit 8716f27 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target This supersedes rust-lang#88879. cc `@Skirmisher` r? `@joshtriplett`
|
Rollup probably related to this pr: @bors r- |
|
@bors r=joshtriplett |
|
📌 Commit 17766f8 has been approved by |
…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#90081 (Make `intrinsics::write_bytes` const) - rust-lang#91643 (asm: Allow using r9 (ARM) and x18 (AArch64) if they are not reserved by the current target) - rust-lang#91737 (Make certain panicky stdlib functions behave better under panic_immediate_abort) - rust-lang#91750 (rustdoc: Add regression test for Iterator as notable trait on &T) - rust-lang#91764 (Do not ICE when suggesting elided lifetimes on non-existent spans.) - rust-lang#91780 (Remove hir::Node::hir_id.) - rust-lang#91797 (Fix zero-sized reference to deallocated memory) - rust-lang#91806 (Make `Unique`s methods `const`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This supersedes #88879.
cc @Skirmisher
r? @joshtriplett