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

["marcus at mc dot pp dot se" <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 marcus@mc.pp.se  2003-06-03 17:14 -------
Subject: Re:  [SH4] sdivsi3_i4 can clobber xd0/xd2


"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?

>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.


> I suggest that you switch to the alternate floating point register bank
> to put your matrix there, and then switch back to use the ordinary
> floating point registers for generic floating point operations.

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.


  // Marcus






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