This is the mail archive of the mailing list for the GCC project.

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

Re: floor on i386

On Sep 12, 2001, Joe Buck <jbuck@synopsys.COM> wrote:

>> > If one had tree nodes or RTL nodes to express the sequence
>> > Save rounding mode
>> > Change rounding mode to round-down
>> > Convert to integer
>> > Restore rounding mode
>> > then perhaps the rounding mode change changes could be moved
>> > outside of loops where they occur, if there were no floating-point
>> > instructions in  the loop that needed the currently set rounding mode.

> Chris Lattner writes:
>> Actually you could probably represent this by adding a "hard register"
>> that effectively is the rounding mode flags.  Doing this seems like a
>> natural way to allow existing optimizations to get rid of the
>> redundancies that are killing GCC here... and you wouldn't have to add any
>> new RTL semantics...

> Seems logical, but then I guess all FP instruction descriptions have to be
> modified to indicate that they read these registers.  I'm not enough of an
> expert to know which approach (extra RTL to represent rounding modes, or
> explicit rounding mode registers) is less painful.  But it seems that
> since changing the rounding mode registers flush the FP pipeline, it may
> not be easy to just treat them as ordinary regs and still get the costs
> right for scheduling.

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

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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