afonso360 opened PR #5888 from riscv64-remove-selectif
to main
:
:wave: Hey,
This PR deletes the
Inst::SelectIf
pseudo instruction from the RISC-V backend. This instruction was only used when lowering theselect_spectre_guard
clif 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 additionalandi
is 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_guard
shouldn't emit any branches. While the old code here is wrong, fixing it will require the split betweenselect
andselect_spectre_guard
again.
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
cmov
on x64 andcsel
on 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_bmask
here its ultimate use ofgen_select_reg
? Would it be bad to rework the lowering ofSelectReg
to 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
bmask
operation! And yeah, I think this is a better lowering than what we currently have. However I check what LLVM produces forbmask
and It's slightly better, so I'm going to reworkbmask
to 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
SelectReg
that I missed.I have somewhat mixed feelings about making
Inst::SelectReg
do 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_bmask
was that it usedgen_select_reg
internally, which will produce jumps to select the result. Sincelower_bmask
no longer relies ongen_select_reg
, I don't see any reason to rework theSelectReg
emit code :)
elliottt submitted PR review.
elliottt created PR review comment:
Since
lower_bmask
can already produce anI128
result, 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_value
didn'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 23 2024 at 13:07 UTC