On Sat, 15 Dec 2012 10:50:01 -0500 Søren Sandmann <sandm...@cs.au.dk> wrote:
> From: Søren Sandmann Pedersen <s...@redhat.com> > > pixman-float-combiner.c currently uses checks like these: > > if (x == 0.0f) > ... > else > ... / x; > > to prevent division by 0. In theory this is correct: a division-by-zero > exception is only supposed to happen when the floating point numerator is > exactly equal to a positive or negative zero. > > However, in practice, the combination of x87 and gcc optimizations > causes issues. The x87 registers are 80 bits wide, which means the > initial test: > > if (x == 0.0f) > > may be false when x is an 80 bit floating point number, but when x is > rounded to a 32 bit single precision number, it becomes equal to > 0.0. In principle, gcc should compensate for this quirk of x87, and > there are some options such as -ffloat-store, -fexcess-precision=standard, > and -std=c99 that will make it do so, but these all have a performance > cost. It is also possible to set the FPU to a mode that makes it do > all computation with single or double precision, but that would > require pixman to save the existing mode before doing anything with > floating point and restore it afterwards. > > Instead, this patch side-steps the issue by replacing exact checks for > equality with zero with a new macro that checkes whether the value is > between -FLT_MIN and FLT_MIN. I just wonder how big is the performance cost for adding an extra comparison operation. Probably much less than using -ffloat-store, -fexcess-precision=standard, and -std=c99 options, but might be interesting to confirm. -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman