On Tue, 7 May 2019, Jakub Jelinek wrote:
On Tue, May 07, 2019 at 09:55:21AM +0200, Jakub Jelinek wrote:
On Tue, May 07, 2019 at 09:48:13AM +0200, Richard Biener wrote:
Will leave the "correctness check" for other folks
but the above is
BTW, as I wanted to be sure about the correctness, I wrote a simple program
(below).
Good idea :-)
And actually it seems that we could optimize the plus1 == plus2 cases
even if HONOR_SIGN_DEPENDENT_ROUNDING (type), because even in fesetenv
(FE_DOWNWARD) mode the testcase prints the first two (in all other modes all
4).
It is very hard to judge what is ok with -frounding-math, because that
mode is already unusably broken (I use a pass-through asm volatile to
protect the arguments and result of every operation instead). One
important aspect of the optimization is whether both operations use the
same rounding mode, or if there may be a call to fesetround in between.
Probably we shouldn't care about -frounding-mode, since anyway it is
likely that it will use some IFN_FANCY_PLUS instead of PLUS_EXPR if it is
ever implemented.
+ (inner_op @0 @1))))))))
Shouldn't you give it a name in the source pattern and return that,
instead of creating a new statement? Or are you doing the operation a
second time on purpose in case the rounding mode changed or to force an
exception?
+ (outer_op @0 @2)
With sNaN, this may raise a second exception where we used to have only
qNaN+0, no? And the handling of exceptions may have changed in between,
etc. Yes, -ftrapping-math is just as broken as -frounding-math.
--
Marc Glisse
