search for: maximumnumb

...writers or CPU architects, but it at least removes the existing operations which were known to be critically flawed, due to them not being associative. The new non-normative operations of interest are defined in clause 9.6: 1. minimum / maximum: returns NaN if any input is NaN. 2. minimumNumber / maximumNumber: return NaN only if *every* input is NaN, even if signaling NaNs are present. Otherwise returns the numerical min / max **ordering –0 before +0**. The behavior of ordering zeros is a critical distinction from the behavior of the old operations, possibly more critical than the signaling NaN behav...

Hi, The specification for the llvm.minnum/llvm.maxnum intrinsics is too unclear right now to usefully optimize. There are two problems. First the expected behavior for signaling NaNs needs to be clarified. Second, whether the returned value is expected to be canonicalized (as if by llvm.canonicalize). Currently according to the LangRef: Follows the IEEE-754 semantics for minNum, which also

...not a NaN; the second > compare + select fixes that one up. > > The first pair of these corresponds to a single (x86-style) MIN/MAX, and > the second turns into a compare followed by (depending on target > instruction set) either a BLEND or some logic ops. > > For minimumNumber/maximumNumber, you should be able to use a similar > construction. Showing the example for minimumNumber here: > > %3 = fcmp olt float %a, %b > %4 = select i1 %3, float %a, float %b ; (a < b) ? a : b > %5 = fcmp ord float %b, %b ; true if !isNaN(b) > %6 = select i1 %5, float %4...

Alex, After looking into this a bit, it looks to me like the best thing to do for targets that do not natively support ISD::MINIMUM and ISD::MAXIMUM would be to fall back to a libcall, since implementing these operations in terms of existing operations is actually rather complicated. Do you think it would make sense to add builtin functions to compiler-rt to implement these operations, or is