[PATCH] D113442: [InstCombine] Enable fold select into operand for FAdd, FMul, FSub and FDiv.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 29 20:10:41 PST 2022


craig.topper added a comment.

In D113442#3282412 <https://reviews.llvm.org/D113442#3282412>, @LuoYuanke wrote:

>> Note that this patch makes IR more consistent (FP ops are treated the same as integer ops). So is the integer codegen also not optimal?
>> https://godbolt.org/z/jd3q6Yq55
>
> I think the integer is also NOT optimal with AVX512 target. See https://godbolt.org/z/Wahef3b3v. For _mm_mask_add_epi64() and _mm_mask_sub_epi64(), it eventually generate extra instructions. But for integer mul, or, and, xor and shl in the test case the InstCombinePass doesn't transform it, so it still generate good code.
>
> I still don't understand what's the benefit to move select instruction before the binary operation (add, sub, mul ...).  Can someone indicate why it is profitable? If it is profitable for general case, I think we can call TTI interface to ask backend if the transform is profitable and then make the decision to transform. We may add below interfaces in TTI.
>
>   +
>   +  bool isLegalMaskedFAdd(Type *DataTye);
>   +  bool isLegalMaskedFSub(Type *DataTye);
>   +  bool isLegalMaskedFMul(Type *DataTye);
>   +  bool isLegalMaskedFDiv(Type *DataTye);
>   +

I believe at least one reason for the int combine was because it reduces the number of uses of the input.

ARM and RISCV both reverse it in the backend for scalars. Though they should probably be using FREEZE to do it.

X86 could probably reverse it for vectors.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113442/new/

https://reviews.llvm.org/D113442



More information about the llvm-commits mailing list