[PATCH] D91242: [RISCV] Custom lowering of SET_ROUNDING
Serge Pavlov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 12 05:57:37 PST 2020
sepavloff added a comment.
In D91242#2388630 <https://reviews.llvm.org/D91242#2388630>, @jrtc27 wrote:
> Would a SELECT not be more friendly to optimisations like known-bits analysis, or does that cause too much code to be emitted in the general case?
Not sure if I understand you correctly, if you mean analyzing the 3 bits of rounding mode bit-by-bit, It think it does not make sense here. It is unlikely that only a part of the bits are known. Rounding mode is specified as a constant or obtained as a result of FLT_ROUNDS or as argument of a function call. Usually it is not obtained by calculations. And yes, in the general case too much code is generated, at least 8 operators, while in this implementation 5 instructions is enough.
================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:225
+ if (Subtarget.hasStdExtD() || Subtarget.hasStdExtF()) {
+ setOperationAction(ISD::SET_ROUNDING, MVT::Other, Custom);
----------------
craig.topper wrote:
> StdExtD implies StdExtF. So I think you only need to check StdExtF
Fixed.
================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:906
+ if (auto CV = dyn_cast<ConstantSDNode>(RMValue)) {
+ uint64_t RM = cast<ConstantSDNode>(RMValue)->getZExtValue();
+ assert(RM <= static_cast<unsigned>(llvm::RoundingMode::MaxIEEEMode));
----------------
craig.topper wrote:
> Why do we need two code paths? Won't the other code constant fold if RMValue is a constant?
Indeed, the general case can be optimized for constant arguments.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91242/new/
https://reviews.llvm.org/D91242
More information about the llvm-commits
mailing list