This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Polyhedron performance regression



On Nov 13, 2006, at 17:12, Richard Guenther wrote:


On 11/13/06, Richard Guenther <richard.guenther@gmail.com> wrote:
exact IEC 60559 semantics for remainder will probably not be suitable
for inlining.  But I can try...

A quick shot for remainder with not honoring signed zeros would be


remainder (x, y) = x - lrint (x / y) * y

I'm probably missing some context here (are x and y single precision?), but if I understand correctly, we're talking about floating point here. Then, doing lrint would be very wrong because the result of the division may be large, even though the final remainder is small enough.

So, it's not just an overflow case, but one that needs
to be computed correctly.

precision is of course an issue, but with cvtsd2siq available we can cover
more than the 52 bits of double precision in the integer part so we only
have intermediate rounding issues left. So a -fflag-unsafe-math- optimizations
expansion which would yield


       movapd  %xmm0, %xmm2
       divsd   %xmm1, %xmm2
       cvtsd2siq       %xmm2, %rax
       cvtsi2sdq       %rax, %xmm2
       mulsd   %xmm1, %xmm2
       subsd   %xmm2, %xmm0

modulo overflow handling (which is a comparison against 0x8000000,
a jump and loading zero as result).

Anyone spots a serious flaw here?
Yes, it won't work for large arguments. Reducing large arguments
is exactly why one would use remainder, so just returning 0 seems
quite dubious. As example, in single precision,
remainder(773094178816, 360) should be 16 exactly.

-Geert


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]