Work around LLVM issues with explicit register in inline asm #75014
Conversation
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| InlineAsmReg::X86(reg) | ||
| if reg as u32 >= X86InlineAsmReg::xmm0 as u32 | ||
| && reg as u32 <= X86InlineAsmReg::xmm15 as u32 => |
There was a problem hiding this comment.
| InlineAsmReg::X86(reg) | |
| if reg as u32 >= X86InlineAsmReg::xmm0 as u32 | |
| && reg as u32 <= X86InlineAsmReg::xmm15 as u32 => | |
| InlineAsmReg::X86(reg) | |
| if RangeInclusive::new(X86InlineAsmReg::xmm0, X86InlineAsmReg::xmm15).contains(®) => |
There was a problem hiding this comment.
Does RangeInclusive work on enums?
There was a problem hiding this comment.
If it is fieldless enum and implements PartialOrd and/or PartialEq I think.
There was a problem hiding this comment.
You can just write (X86InlineAsmReg::xmm0..=X86InlineAsmReg::xmm15).contains(®), too.
|
☔ The latest upstream changes (presumably #75070) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Looks fine I think, but I'd suggest avoiding waiting on reviews from me where possible. r? @nagisa |
|
This mentions LLVM issues and that this is a workaround. A couple of questions: is this really a LLVM issue (besides the fact that LLVM fires an assertion rather than diagnostic callback)? If so, is there a report upstream? If not, could this PR be retitled to something else (just so that it is easier to search for/understand in the future). Otherwise @bors r+ |
|
📌 Commit 9198e8a has been approved by |
bors
added
S-waiting-on-bors
|
I'm not sure it is a bug in LLVM but rather just LLVM being very picky about what types you can use with a particular register type. This PR adjusts the types in rustc to match what LLVM expects. |
|
☀️ Test successful - checks-actions, checks-azure |
Fixes #74658