================ @@ -3830,6 +3876,14 @@ SDValue SystemZTargetLowering::lowerSELECT_CC(SDValue Op, ISD::CondCode CC = cast<CondCodeSDNode>(Op.getOperand(4))->get(); SDLoc DL(Op); + // SELECT_CC involving f16 will not have the cmp-ops promoted by the + // legalizer, as it will be handled according to the type of the resulting + // value. Extend them here if needed. ---------------- JonPsson1 wrote:
Patch updated per review. Found more cases that escaped the general promotion OpAction of half: IS_FPCLASS: Without custom handling for f16, SelectionDAGBuilder implements this with integer logic, which might be better than a conversion call to float + tceb, but assuming it is preferrable to "do the same" still: Adding also the f16 case for the custom handling. This node can't just be promoted as SelectionDAGBuilder would then expand it early. ISD::SINT_TO_FP, ISD::UINT_TO_FP, ISD::STRICT_SINT_TO_FP, ISD::STRICT_UINT_TO_FP: Legalizer maps OpAction by the integer op, so need custom handling to deal with f16. The f16->i32 fptoui tests result in TargetLowering converting them to fptosi. I noticed when trying that with i16, the i16 after type legalization has become i32, so the TargetLowering sees the f16->i32 conversion all the same, even though the source type was i16. I guess this should be ok also? Is there a need for i16->f16 / f16->i16 tests? Will continue to search for other opcodes that need handling. https://github.com/llvm/llvm-project/pull/109164 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
