search for: fmax

Hi, I’d like to re-propose adding intrinsics for fmin / fmax. These can be used to implement the equivalent libm functions as defined in C99 and OpenCL, which R600 and AArch64 at least have instructions with the same semantics. This is not equivalent to a simple fcmp + select due to its handling of NaNs. This has been proposed before, but never delivered (...

...=c("light green", "green", "dark green"),* * legend = rownames(coral))* Here is the *head(Coral) *before station col removal and t() Seamount Station Depth Pico Nano Micro Total_Ch 185 Coral 1401 Surface 0.216 3.270 4.240 7.726 186 Coral 1401 Fmax 0.359 3.890 4.900 9.149 187 Coral 1401 Below 0.178 1.360 1.210 2.748 188 Coral 1402 Surface 0.231 4.140 3.670 8.041 189 Coral 1402 Fmax 0.863 4.340 3.750 8.953 190 Coral 1402 Below 0.176 0.386 0.214 0.776 So I use the same code for the six other seamou...

… actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations). So I think your proposed semantics are perfectly reasonable....

...hofer.de/> > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stephen Canon > Sent: Thursday, August 14, 2014 18:03 > To: Matt Arsenault > Cc: llvm-commits; LLVM Developers Mailing List > Subject: Re: [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics > > … actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]: > > minNum(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN....

...easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. —Owen > On Aug 18, 2014, at 12:00 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote: > > would it be in scope to have intrinsics analogues for fmin/fmax that return Nan if either arg is a nan? > Julia Lang and GHC Haskell are both likely to change their definitions of min/max on floats/doubles to return nan if either arg is Nan. > See here  <https://github.com/JuliaLang/julia/issues/7866> for the julia lang discussion, and I'm ami...

.... I could even be convinced if we wanted to add a pair of NaN-propagating intrinsics as well, for targets and languages that want those semantics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are equivalent to C’s fmin/fmax, but not std::min/std::max or Java(script)’s min/max. > > —Owen > > >> On Sep 15, 2014, at 12:26 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> >> Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-pr...

Dear Justin, I am trying to add the support for some OpenCL builtin functions to the PTX backend. The attached file represent the first stub of a patch for the fmax builtin function. The test case I am trying is the following: define ptx_device float @f(float %x, float %y) { entry: %z = call float @fmax(float %x, float %y) ret float %z } declare float @fmax(float, float) But at the moment llc crashes saying that "calls are not supported", thi...

Given IEEE-754's sway, and its saying what it does on this point, but given also the popularity of NaN-propagating min and max, how about a compromise? We add intrinsics following the IEEE-754 semantics, but we also follow IEEE-754 (and ARMv8) in renaming them to minnum and maxnum, to clarify which interpretation these intrinsics are using. -------------- next part -------------- An HTML

On Wed, Nov 16, 2011 at 8:05 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Dear Justin, > > I am trying to add the support for some OpenCL builtin functions to > the PTX backend. > The attached file represent the first stub of a patch for the fmax > builtin function. > First off, thanks for helping to improve the PTX back-end! There are really two main issues here. First, OpenCL built-in functions do not belong in the PTX back-end. These will be implemented in the libclc library (http://www.pcc.me.uk/~peter/libclc). The back-end w...

...wrote: > >>>> > >>>> Dear Justin, > >>>> > >>>> I am trying to add the support for some OpenCL builtin functions to > >>>> the PTX backend. > >>>> The attached file represent the first stub of a patch for the fmax > >>>> builtin function. > >>> > >>> First off, thanks for helping to improve the PTX back-end! > >>> There are really two main issues here. First, OpenCL built-in > functions > >>> do not belong in the PTX back-end. These will be...

> On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > > More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing. Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. > > The IEEE version can also be

...recognized rather than looking for compare-select sequences. The suggestion was to change compare-selects into max and min intrinsic calls during instcombine. The intrinsics to add are: declare iN llvm.{smin,smax}.iN(iN %a, iN %b) declare iN llvm.{umin,umax}.iN(iN %a, iN %b) declare fN llvm.{fmin,fmax}.fN(fN %a, fN %b) What does the community think? Paul

...;>> >> >>>> Dear Justin, >> >>>> >> >>>> I am trying to add the support for some OpenCL builtin functions to >> >>>> the PTX backend. >> >>>> The attached file represent the first stub of a patch for the fmax >> >>>> builtin function. >> >>> >> >>> First off, thanks for helping to improve the PTX back-end! >> >>> There are really two main issues here.  First, OpenCL built-in >> >>> functions >> >>> do not belong...

...hat it's a popular flag. > Also, as a practical issues, many GPUs have ISA-level support for the > IEEE-conforming version. Some (all?) of the AMD GPUs that Matt cares about > support it, and PTX has native operations for it as well. The IR expansion > of an IEEE-conforming fmin/fmax is at least three compares + selects, which > makes it very difficult to pattern match for these targets. > It's 2 compares + selects: float nan_swallowing_fmin(float a, float b) { return b != b ? a : (a < b ? a : b); } which is within the realm of pattern-matching. > > Th...

...gt;>>> Dear Justin, > >> >>>> > >> >>>> I am trying to add the support for some OpenCL builtin functions to > >> >>>> the PTX backend. > >> >>>> The attached file represent the first stub of a patch for the fmax > >> >>>> builtin function. > >> >>> > >> >>> First off, thanks for helping to improve the PTX back-end! > >> >>> There are really two main issues here. First, OpenCL built-in > >> >>> functions > >&...

...compare-select sequences. > > The suggestion was to change compare-selects into max and min intrinsic calls during instcombine. > > The intrinsics to add are: > declare iN llvm.{smin,smax}.iN(iN %a, iN %b) > declare iN llvm.{umin,umax}.iN(iN %a, iN %b) > declare fN llvm.{fmin,fmax}.fN(fN %a, fN %b) > > What does the community think? It seems inevitable. For the floating point version, please make it very clear what the behavior of max(-0,+0) and related cases are. This also means stuff that matches compare/select idioms (e.g. llvm/Support/PatternMatch.h) will need...

...>>> >> >> >>>> I am trying to add the support for some OpenCL builtin functions >> >> >>>> to >> >> >>>> the PTX backend. >> >> >>>> The attached file represent the first stub of a patch for the fmax >> >> >>>> builtin function. >> >> >>> >> >> >>> First off, thanks for helping to improve the PTX back-end! >> >> >>> There are really two main issues here.  First, OpenCL built-in >> >> >>>...

...;> >>>> I am trying to add the support for some OpenCL builtin > functions > >> >> >>>> to > >> >> >>>> the PTX backend. > >> >> >>>> The attached file represent the first stub of a patch for > the fmax > >> >> >>>> builtin function. > >> >> >>> > >> >> >>> First off, thanks for helping to improve the PTX back-end! > >> >> >>> There are really two main issues here.  First, OpenCL built- > in >...

> 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"...

...to both operands. This means that fmin(+/-0.0, +/-0.0) could return either -0.0 or 0.0. This first line is a lie. This isn’t true for the case of signaling NaNs. The IEEE rule is if either input is a signaling nan, it returns a quieted NaN, not the other operand. The C standard definition for fmin/fmax do not make this distinction, and just return the other operand. The constant folding for these currently match the libm behavior, returning the non-NaN operand and will never quiet. The default lowering for these operations also just directly calls the system’s fmin/fmax. Additionally, the IEEE...