Force overflow/underflow in generic std.math implementations

[ibuclaw]

If an overflow or underflow occurred in one of exp, expm1, or exp2 we should return infinity or 0.0 computationally at runtime, forcing overflow/underflow ieeeFlags to be set. At the same time, this still respects the fast path in CTFE.

This should fix the exp/exp2 and ieeeFlags unittests for non-x86 targets (though only tested on gdc x86_64).

[ibuclaw]

For reviewers notes, it's these particular tests: 70e5e94

[dnadlinger]

Maybe add a short comment about why CTFE is different?

[ibuclaw]

You mean, that we don't care about ieeeFlags in CTFE because floats operations are done using a synthetic type?

[dnadlinger]

Yeah.

[ibuclaw]

Special cases. Raises an overflow or underflow flag accordingly,
except in the case for CTFE, where there are no hardware controls.

[WalterBright]

doesn't this multiply make things slow?

[ibuclaw]

Slow how? This operation is deliberate because I didn't 't want the optimizer to fold the operation so that nohardware flag is raised.

[9il]

CTFE code returns +0.0, but runtime -0.0. This is a bad practice for math.
Please check other signs too.

[ibuclaw]

Rather than copysign the parameters, passing the result literal should do for now.

[ibuclaw]

So, apart from @9il comments what's halting progress?

Does anyone have any alternative suggestion that would deliberately raise a fp exceptionwithout risk of being folded away by an optimizing compiler?

[ibuclaw]

Re-based and addressed @9il's nit.

[9il]

Unittest looks important to me because optimization control.

Off topic:

addressed @9il's nit

Google translate makes me feel strange because nit.

[ibuclaw]

Unittest looks important to me because optimization control.

The unittests already exist that test FP control flags, although they only test the exception flags after calling exp2()

Google translate makes me feel strange because nit.

Well, when you have wavy-long hair, these things can happen. :-)

[9il]

LGTM

[9il]

Can we now make it template?

[quickfur]

ping
What's happening with this PR? Are we ready to merge, or is this waiting for something else to happen first?

[9il]

ping
What's happening with this PR? Are we ready to merge, or is this waiting for something else to happen first?

Yes, it can be merged.

[ibuclaw]

Thanks. @andralex - dare I ask you for approval?

[tsbockman]

@ibuclaw Why all the calls to copysign()?

They don't appear to do anything, since the sign bit for both operands is always the same.

[ibuclaw]

I answered this last year.

This operation is deliberate because I didn't want the optimizer to fold the operation so that no hardware flag is raised.

Essentially, I want runtime to execute this so that the hardware flag is raised. If CTFE does the job, it returns the answer with no hardware exception. Which defies the whole point of this PR.

If you have any alternatives, I'm all ears.

[tsbockman]

@ibuclaw

If you have any alternatives, I'm all ears.

This does the trick on all three compilers, and with better codegen than abusing copysign():

pragma(inline, true)
real ieeeDoOverflow(bool neg) @safe nothrow @nogc
{
    // only x87 instructions set ieeeFlags
    RealRep!real big = void;
    big.mantBits = cast(big.Mant)1 << big.fracExDig;
    end!(-1)(big.allBits) = cast(big.Exp)((neg << big.signShift) | big.expRawMaxNorm);

    big += big;
    return big;
}

unittest
{
    resetIeeeFlags();
    assert(isIdentical(ieeeDoOverflow(false), real.infinity));
    assert(ieeeFlags.overflow);

    resetIeeeFlags();
    assert(isIdentical(ieeeDoOverflow(true), -real.infinity));
    assert(ieeeFlags.overflow);
}

pragma(inline, true)
real ieeeDoUnderflow(bool neg) @safe nothrow @nogc
{
    // only x87 instructions set ieeeFlags
    RealRep!real small = void;
    small.mantBits = cast(small.Mant)1 << small.fracExDig;
    end!(-1)(small.allBits) = cast(small.Exp)(neg << small.signShift);

    small *= real.min_normal;
    return small;
}

unittest
{
    resetIeeeFlags();
    real zero = 0;
    assert(isIdentical(ieeeDoUnderflow(false), zero));
    assert(ieeeFlags.underflow);

    resetIeeeFlags();
    zero = -zero;
    assert(isIdentical(ieeeDoUnderflow(true),  zero));
    assert(ieeeFlags.underflow);
}

EDIT: Fixed. This would require my RealRep PR, though.

[ibuclaw]

I don't think that would work either. It's not CTFE that is the problem, it's the optimizer. It will (or should) see through those operations in release mode.

[tsbockman]

@ibuclaw

I don't think that would work either.

I fixed it. (The version you saw last worked on DMD, but I guess I forgot to retest it for GDC and LDC release mode before posting.)

[andralex]

I'll pull, @ibuclaw feel free to improve by using @tsbockman's idea

[andralex]

Auto-merge toggled on

[tsbockman]

feel free to improve by using @tsbockman's idea

I can do that later, if RealRep is accepted.

[ibuclaw]

Thanks. @tsbockman ok. I'll have a re-review when I get round to it. How much does it differ from the previous two attempts to move pointer casting into unions?

[tsbockman]

@ibuclaw

How much does it differ from the previous two attempts to move pointer casting into unions?

I wrote an answer in the RealRep comments.