kpn added a comment. In D115804#3202479 <https://reviews.llvm.org/D115804#3202479>, @sepavloff wrote:
> In D115804#3201681 <https://reviews.llvm.org/D115804#3201681>, @spatel wrote: > >> In D115804#3201044 <https://reviews.llvm.org/D115804#3201044>, @craig.topper >> wrote: >> >>> What's the plan for constrained intrinsics versions of these intrinsics? >>> The IRBuilder calls for CreateFPToSI and CreateFPToUI are strict FP aware, >>> but this new code isn't. >> >> Not sure. cc'ing @kpn @sepavloff @andrew.w.kaylor >> The saturating intrinsics implement non-standard behavior for C languages >> AFAIK, so we might want to warn if someone tries to use >> "-fno-strict-float-cast-overflow" and "-ffp-exception-behavior=strict" at >> the same time? Or we try to support that corner case by adding even more FP >> intrinsics? > > Conversion `float`->`int` depends on rounding mode. At least on some ML cores > this conversion is made with saturating semantics. So ability to specify > rounding mode would be useful for such targets. What about the idea of using operand bundles? I think the idea there was to avoid having to add new intrinsics for every target-specific floating point intrinsic. But maybe the idea will work here as well? I think we definitely need to warn when -ffp-exception-behavior=strict or =maytrap is given and incompatible options are also used with it. In that case we should also be disabling the -ffp-exception-behavior option and the related #pragmas plus warning about the disabling. We already disable+warn when our backend doesn't support strictfp, we can do the same here. If someone in the future wants to implement the support then that'll be nice. But in the meantime we shouldn't be silently letting people use strictfp plus a contradictory option. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D115804/new/ https://reviews.llvm.org/D115804 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
