Hi! On Thu, May 05, 2022 at 05:30:58PM +0800, HAO CHEN GUI wrote: > On 5/5/2022 下午 4:30, Kewen.Lin wrote: > > on 2022/5/5 16:09, Richard Biener via Gcc-patches wrote: > >> On Thu, May 5, 2022 at 10:07 AM HAO CHEN GUI via Gcc-patches > >> <gcc-patches@gcc.gnu.org> wrote: > >>> This patch skips constant folding for fmin/max when either argument > >>> is sNaN. According to C standard, > >>> fmin(sNaN, sNaN）= qNaN, fmin(sNaN, NaN) = qNaN > >>> So signaling NaN should be tested and skipped for fmin/max in match.pd. > >>> > >>> Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
The C standard does not talk about sNaNs *at all*, in any released version of the standard. And the C2x drafts do not talk about signaling arguments for fmin/fmax specifically, so it should just raise an error like any other floating operation with an sNaN arg will. This means we have to make sure to not optimise away all operations if there may be an sNaN (and we have HONOR_SNANS for the mode in use). You never have to convert to a qNaN manually. Instead, any normal operation on the sNaN will raise the exception, and convert to the qNaN. There is no sane way you can raise the exception manually, so you should make sure we end up with a real operation in the RTL, and then generate proper machine code for it as well. See rs6000 extendsfdf2 for example, for that last part. And of course both the gimple min_expr and the RTL smin are not defined for NaN inputs at all anyway :-P Segher
