Mar 15 2016
Mar 12 2016
Jan 29 2016
The signbit of NaN explicitly has no meaning, so there's no concern there. LGTM.
Jan 11 2016
Dec 4 2015
Dec 2 2015
Abandoned for D15165.
This is mostly http://reviews.llvm.org/D14891 with a test case added, but D14891 also fixed a second very minor issue: that the "else if" should just be "if". Also, majnemer made a few style suggestions there that it would be nice to adopt. Either way, we should merge the two patches. This can be the canonical one if you want to update it.
Nov 30 2015
Can we assume default rounding for now, change the operand to X86::FNMSUB, remove the nsz check, and leave a 'TODO' comment to revisit this after rounding mode support is added? I think it would be better to have this transform be more general if we can.
As updated, this seems fine to me.
Nov 28 2015
Could this be resolved by using -0 as the constant instead of 0 in non-fast-math mode?
Something that also probably needs to be thought about is what will be the default behavior for clang and how to control it?
Nov 20 2015
Nov 18 2015
As long as we're really going to dig into the addition-chain issue, why are we duplicating Reassociate::buildMinimalMultiplyDAG here?
Nov 17 2015
This looks good to me now. One of the owners should probably sign off on it too.
Hence the "something like". We should really just be able to pull and integer value out of APFloat (but again, outside the scope of this change). Short-term, I think you can use V.convert(APFloat::IEEEdouble, ...) to get something that *can* be converted to double.
Nov 16 2015
I went ahead and added isInteger( ) to APFloat (r253254). You can use that to simplify some of the logic and make it somewhat more general.
Nov 5 2015
The one thing that's a little bit weird here is cases like x = -1, y = 4; log(pow(-1, 4)) is 0, but 4*log(-1) is NaN. That's a dramatic difference even for fast-math. Do we find exact integer exponents before we get to this point?
Seems reasonable from a mathematical perspective.
Nov 4 2015
Additionally test contraction of compound assignment expressions.
Nov 3 2015
I'd like to see this made generic so it applies to any 1-to-1 libm function whose inverse is available, since the same pattern applies for logN(expN(x)), asinh(sinh(x)), atanh(tanh(x)), etc ...
Oct 30 2015
Seems reasonable to me. One of the owners should sign off on it.
Oct 26 2015
I'd like to propose a mildly different design; I'd phrase the two flags using a positive perspective:
- nexc: Assume that floating-point exceptions are not relevant.
- nrnd: Assume that the rounding-mode is round-to-nearest (ties even).
This has the nice property that fast is the union of all flags and, in general, keeps things consistent with all the other fast math flags. The general pattern is that adding flags permits further optimization; places where this is violated have been a wellspring of bugs (namely volatile).
As suggested by David, this should be fast-math only. It's roughly equivalent to re-association of multiplication. Besides rounding differences, this changes overflow and underflow behavior quite dramatically. Consider x = 1000, y = 0.001. pow(exp(x), y) = pow(inf, 0.001) = inf, whereas exp(x*y) = exp(1).
Sep 25 2015
Sep 23 2015
Sep 22 2015
Sep 21 2015
Sorry for only bringing this up now, but this doesn't look right. I think if an FRINTX does get created it probably should be treated specially. You'd mostly only do so (by calling "rint") if you actually cared about the otherwise unmodeled FPSR flags, wouldn't you?
Removed AArch64DAGToDAGISel::SelectFPConvertWithRound() and SelectLIBM() in favor of TD patterns.
Sep 18 2015
Sep 15 2015
Looks good to me. Apologies for delay in getting to this one.
Sep 14 2015
Jun 22 2015
May 12 2015
Looks reasonable to me. Someone else will need to answer your question about gnu_*_ieee aliases.
Mar 9 2015
I'm uncomfortable with this change, as I believe that it makes the llvm conversions incompatible with IEEE-754 conversion (which round according to the dynamic rounding mode unless they're in a (language defined) block with static rounding attribute).
Thanks for keeping after this. Looks good to me.
Dec 4 2014
I'm rather dubious of this. Do you have timing info to support this?
Oct 17 2014
Apologies for delay in looking at this, I'm on vacation this week.
Oct 9 2014
Thanks for working on this, Chandler, it’s an enormous improvement over the current state of affairs.
Sep 17 2014
I think it makes sense to clamp out-of-range values. Even though the C language cast is UB, there’s a fairly clear “right” thing to do, and we can do it without excessive performance penalty. Let’s follow libgcc here and saturate.
Jun 10 2014
LGTM. I'm no expert on the BSD environment, but this seems perfectly reasonable.