afonso360 opened PR #5888 from riscv64-remove-selectif to main:
:wave: Hey,
This PR deletes the
Inst::SelectIfpseudo instruction from the RISC-V backend. This instruction was only used when lowering theselect_spectre_guardclif instruction in a specific case of the input being preceded by anicmp. That being said, the instruction doesn't really do anything different from the regular select.This PR removes the instruction and defaults to the regular
Inst::Select. We get pretty much exactly the same codegen, with the exception that an additionalandiis now added into the generated code. That doesn't seem to be to bad, and we can probably remove it with some additional effort if needed.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
select_spectre_guardshouldn't emit any branches. While the old code here is wrong, fixing it will require the split betweenselectandselect_spectre_guardagain.
afonso360 created PR review comment:
I don't think we have a way of doing that with the base ISA on RISC-V. Do you know how other compilers handle this?
afonso360 submitted PR review.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
You can use bit masking: https://github.com/RustCrypto/utils/blob/0256fff4d67edb4956f5200b877f41038c4ef7e7/cmov/src/portable.rs#L46-L47
afonso360 submitted PR review.
afonso360 created PR review comment:
Right, but I think that can still be speculated on right? My understanding is that we used
cmovon x64 andcselon AArch64 because we had architectural guarantees that they wouldn't be speculated on?I'm up for rewriting this if it does prevent speculation though.
afonso360 edited PR review comment.
afonso360 edited PR review comment.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
While it is technically possible, I don't think any cpu would see a benefit in pattern matching this pattern and turning it back into a conditional branch that the branch predictor can speculate.
afonso360 edited PR review comment.
jameysharp submitted PR review.
jameysharp created PR review comment:
What do you two think is the current state of this PR? I'm not sure what conclusions you've come to from this conversation.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
I guess this PR is fine for now, but I did like to see a proper implementation of select_spectre_guard in the future.
afonso360 created PR review comment:
I have a version of this pretty much ready to go, but got distracted by the fuzzer SIMD stuff! I'll clean it up a little bit and push those commits.
afonso360 submitted PR review.
afonso360 updated PR #5888 from riscv64-remove-selectif to main.
afonso360 updated PR #5888 from riscv64-remove-selectif to main.
afonso360 updated PR #5888 from riscv64-remove-selectif to main.
afonso360 has marked PR #5888 as ready for review.
afonso360 requested elliottt for a review on PR #5888.
afonso360 requested wasmtime-compiler-reviewers for a review on PR #5888.
afonso360 updated PR #5888.
elliottt submitted PR review.
elliottt submitted PR review.
elliottt created PR review comment:
Is the reason we can't use
lower_bmaskhere its ultimate use ofgen_select_reg? Would it be bad to rework the lowering ofSelectRegto take this approach instead?
elliottt created PR review comment:
;; non_zero = ((normalized | ((!normalized) + 1)) >> 63) & 1
afonso360 updated PR #5888.
afonso360 submitted PR review.
afonso360 created PR review comment:
I hadn't even considered that this was a
bmaskoperation! And yeah, I think this is a better lowering than what we currently have. However I check what LLVM produces forbmaskand It's slightly better, so I'm going to reworkbmaskto use that and use that here.
afonso360 updated PR #5888.
afonso360 submitted PR review.
afonso360 created PR review comment:
I'm much happier with the output of this now, Thanks!
I'm now re-reading your comment, and realizing there was a second part about
SelectRegthat I missed.I have somewhat mixed feelings about making
Inst::SelectRegdo something like this, It would be quite a bit longer (~4 instructions I think?). But it would be really nice since we could move it entirely into ISLE. However I don't think that justifies it, it's a really common operation in the backend.I'm willing to be persuaded otherwise though!
elliottt submitted PR review.
elliottt created PR review comment:
My worry with recommending
lower_bmaskwas that it usedgen_select_reginternally, which will produce jumps to select the result. Sincelower_bmaskno longer relies ongen_select_reg, I don't see any reason to rework theSelectRegemit code :)
elliottt submitted PR review.
elliottt created PR review comment:
Since
lower_bmaskcan already produce anI128result, I think the following should be equivalent:(wide_mask Reg (lower_bmask ty cmp_ty cmp)) ;; Using the mask above we can select either `x` or `y` by ;; performing a bitwise `and` on both sides and then merging them ;; together. We know that only the bits of one of the sides will be selected. ;; TODO: We can use `andn` here if we have `Zbb` (lhs ValueRegs (gen_and arg_ty x wide_mask)) (rhs ValueRegs (gen_and arg_ty y (gen_bnot arg_ty wide_mask))))
elliottt edited PR review comment.
elliottt edited PR review comment.
afonso360 updated PR #5888.
elliottt submitted PR review.
elliottt submitted PR review.
elliottt created PR review comment:
It would be nice if
normalize_cmp_valuedidn't normalize constants whose value already fit in the target type, but there's no need to fix that on this PR.
afonso360 merged PR #5888.
Last updated: Dec 13 2025 at 19:03 UTC