> It seems inevitable. For the floating point version, please make it very > clear what the behavior of max(-0,+0) and related cases are.Along these lines, AArch64 has an instruction "FMAXNM". It returns the maximum if neither value is NaN, but returns the number if just one value is NaN. This is in addition to an "FMAX" which propagates NaNs. I suspect you'll just want to consider this as an "oh yes, make sure that the result is NaN if either input is" advisory notice, but I haven't actually thought through the details of implementation yet. Tim.
On Wed, Dec 5, 2012 at 10:43 PM, Tim Northover <t.p.northover at gmail.com> wrote:>> It seems inevitable. For the floating point version, please make it very >> clear what the behavior of max(-0,+0) and related cases are. > > Along these lines, AArch64 has an instruction "FMAXNM". It returns the > maximum if neither value is NaN, but returns the number if just one > value is NaN. This is in addition to an "FMAX" which propagates NaNs. > > I suspect you'll just want to consider this as an "oh yes, make sure > that the result is NaN if either input is" advisory notice, but I > haven't actually thought through the details of implementation yet.Given the recent fast-math flags commit, what about the inverse? ("I guarantee that inputs are not NaNs") In this regard min/max look like other floating point instructions to me. Does it make sense to add them as instructions so that they can profit from fast-math flags? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
Hi,>> Along these lines, AArch64 has an instruction "FMAXNM". It returns the >> maximum if neither value is NaN, but returns the number if just one >> value is NaN. This is in addition to an "FMAX" which propagates NaNs. >> >> I suspect you'll just want to consider this as an "oh yes, make sure >> that the result is NaN if either input is" advisory notice, but I >> haven't actually thought through the details of implementation yet. > > Given the recent fast-math flags commit, what about the inverse? ("I > guarantee that inputs are not NaNs")It's certainly a point to consider in general, but I don't think it would help in our case. I've not looked at the instruction timings for any of our CPUs, but I can't imagine FMAXNM being any different from FMAX. If that's right, it doesn't matter whether NaNs are present computationally; it becomes a question of what semantics you actually want. Tim.