[Bug target/6526] [SH4] sdivsi3_i4 can clobber xd0/xd2

["joern dot rennecke at superh dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6526



------- Additional Comments From joern.rennecke@superh.com  2003-06-03 18:39 -------
Subject: Re:  [SH4] sdivsi3_i4 can clobber xd0/xd2

"marcus@mc.pp.se" wrote:
> "joern.rennecke@superh.com" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> > The patch you provided does not make integer division slower,
> 
> Well, that's a good thing isn't it?

Oops, scratch that 'not'.
FWIW, division by small numbers can be made faster by using single
precision, but that makes handling larger numbers a bit slower.
	
> >it also causes it to give different results when the floating point
> >rounding mode is changed, or trap when e.g. inexact traps are enabled.
> 
> This is already the case with several other implementations in
> lib1funcs.asm, so presumably changing rounding/trap mode is also "not
> supported", and fixing that is a separate issue.

Oops, I forgot that changing the rounding mode only changes the number
of guard bits available, but this is not an issue with doing 32 bit/32 bit
divisions in double precision, as there are plenty of spare bits.  When
you calculate x/y, this results either in an exact integer, or a fraction
that is at least 1/y larger than the correct integral result for truncating
divide, and at least 1/y less than the next larger integer.
The smallest representable delta is x/y/2**51, which is smaller than
1/y/2**19 .  So the ftrc at the end will do the right rounding, no matter
how the floating point divide was rounded.

> That's what I'm doing.  The trick comes when applying a transformation
> operation to the matrix.  Then the operation matrix is loaded into the
> "ordinary" floating point registers, and four ftrv operations are
> carried out to compute the new matrix.  The new matrix however ends up
> in fr0-fr15, but it's just a matter of doing a frchg and it becomes
> the new xmtrx, and I get a new set of ordinary floating point
> registers.  Unless I'm very much mistaken, this is the whole idea of
> the frchg instruction.  The alternative would be to copy all the
> computed values manually, which would be much slower.

So, are you using integer division somewhere in this loop?
Or are you doing an uneven number of iterations, so you end up
with a switched register set at the end?
	




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.