Re: floor on i386

[Jan Hubicka <jh@suse.cz>]

> It would probably be best to introduce a hard register to indicate the
> rounding mode, and use OPTIMIZE_MODE_SWITCHING to do as few mode
> changes as possible.  For reference, have a look at the SH4
> implementation of floating-point support, that defines an explicit
> floating-point control register, mode-switching RTL and USEs that

The USEs itself are problem - you loose a lot of optimizations then.
The trick can be to lower code before reload using pre-reload splitting.

Major problem still remains in reload.
If we don't want to get exact IEEE by setting proper precisity before each
mathematic operation (as SH4 does IMO), we will run into problems with spills ,
since these can be put in place control word is set to some wrong value
resutlting in wrong rounding before storing.

Thats the main purpose why my original patch didn't contained it.

The problem can be solved by mode switching pass after reload, when all spills
are visible - you use existing pass before reload to compute control word values
as these needs pseudos and after reload just insert fldcw/fstcw at strategic places.

If you insert them at last optimal position in code, you will get them after the
lazy code to compute control word inserted by pre-reload pass.

As disussed with Timothy, the benefits are relativly small compared to the first
half (computing control word values optimally), as CPUs do have hardware bypass.

> register in all instructions that depend on the floating-point mode,
> indicating in an attribute which mode the register is supposed to be
> in.  The difference is that SH4 uses the floating-point control
> register to switch between single- and double-precision operations,
> that have the same encoding but different behavior depending on the
> state of the control register.  Modeling mode switching for purposes
> of rounding on x86 should be far simpler.  In fact, I'm not even sure
> you'd need the hard register: just define unspec patterns that switch
> back and forth and you're done.
You need scheduling barrier, but it is big problem.

Honza
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me