[Bug target/29969] should use floating point registers for block copies

["olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-07-15 18:43:59 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > This could be a disaster if floating point exceptions are enabled, as it would
> > trigger an exception whenever some part of the block was an invalid floating
> > point number.
> > One would at least need to save/restore the floating point exception flags
> > around such a block copy.
> 
> If that is an issue is target specific.  First, if all floating point loads
> detect loading invalid floating point numbers, and sencond, if floating point
> exceptions are used for the target in practical terms.
> E.G. for the SH4 (at least SH4-100 / SH4-200), you get always a floating
> point exception if the exception is enabled and it could happen for any
> input data, so it is not very popular to enable it.

JÃrn, I know it's been a while since you worked on the SH port...

According to SH4, SH4A and SH2A manuals these are the following exceptions
that could be triggered by FMOV instructions:

SH4 / SH4A:
 - Data TLB miss exception
 - Data protection violation exception
 - Initial page write exception
 - Data address error

SH2A:
 - Address error

... plus the 'FPU disabled exception'.
As far as I understand the manuals, FPU exceptions are only raised for
FPU arithmetic, not for loads/stores.
If this is true, using 64 bit fmov for block moves could be beneficial.
Still, I'd not enable this by default but allow the user to turn it on
with an -m option.