summaryrefslogtreecommitdiffstats
path: root/docs/vmware-guest.html
diff options
context:
space:
mode:
authorMatt Turner <[email protected]>2015-03-10 17:55:21 -0700
committerMatt Turner <[email protected]>2015-03-18 21:06:26 -0700
commitdd0d3a2c0fb388745519c8a3be800720541eccfe (patch)
treec825d6c3580455cee47ce55610767ed2eda39bac /docs/vmware-guest.html
parentbb22aa08e4b08c9688c5d5c6558ac01663d0163a (diff)
mesa: Replace _mesa_round_to_even() with _mesa_roundeven().
Eric's initial patch adding constant expression evaluation for ir_unop_round_even used nearbyint. The open-coded _mesa_round_to_even implementation came about without much explanation after a reviewer asked whether nearbyint depended on the application not modifying the rounding mode. Of course (as Eric commented) we rely on the application not changing the rounding mode from its default (round-to-nearest) in many other places, including the IROUND function used by _mesa_round_to_even! Worse, IROUND() is implemented using the trunc(x + 0.5) trick which fails for x = nextafterf(0.5, 0.0). Still worse, _mesa_round_to_even unexpectedly returns an int. I suspect that could cause problems when rounding large integral values not representable as an int in ir_constant_expression.cpp's ir_unop_round_even evaluation. Its use of _mesa_round_to_even is clearly broken for doubles (as noted during review). The constant expression evaluation code for the packing built-in functions also mistakenly assumed that _mesa_round_to_even returned a float, as can be seen by the cast through a signed integer type to an unsigned (since negative float -> unsigned conversions are undefined). rint() and nearbyint() implement the round-half-to-even behavior we want when the rounding mode is set to the default round-to-nearest. The only difference between them is that nearbyint() raises the inexact exception. This patch implements _mesa_roundeven{f,}, a function similar to the roundeven function added by a yet unimplemented technical specification (ISO/IEC TS 18661-1:2014), with a small difference in behavior -- we don't bother raising the inexact exception, which I don't think we care about anyway. At least recent Intel CPUs can quickly change a subset of the bits in the x87 floating-point control register, but the exception mask bits are not included. rint() does not need to change these bits, but nearbyint() does (twice: save old, set new, and restore old) in order to raise the inexact exception, which would incur some penalty. Reviewed-by: Carl Worth <[email protected]>
Diffstat (limited to 'docs/vmware-guest.html')
0 files changed, 0 insertions, 0 deletions