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]
Other format: [Raw text]

Re: patch to fix rtl documentation for new floating point comparisons

On Wed, 18 Feb 2015, Kenneth Zadeck wrote:

> > I think the norm is dynamic, because that's what was in IEEE 754-1985, 
> > with static rounding added more recently on some processors, because of 
> > IEEE 754-2008.  (There are other variants - IA64 having multiple dynamic 
> > rounding mode registers and allowing instructions to specify which one the 
> > rounding mode is taken from.)
> the first ieee standard only allowed the dynamic model.  the second 
> allows the static model.  while dynamic is more common, there are/were 
> architectures that are fully static.  i believe that the first sparks 
> were fully static and this was why the standard changed. ( i could be 
> completely wrong on which arch was the first fully static).  the private 
> port that i am working on is currently fully static, but i am trying to 
> change that.  code generation of a dynamic program on a fully static 
> machine is gruesome.
> my point here is that there are fully static machines so do not do 
> anything that precludes this.

The C99 standard was hardly designed for such systems, given the 
expectation that you can set the rounding mode with fesetround and then 
have it affect library functions (those that are fully-defined operations 
such as sqrt and fma, that is).  It's not that you can't implement it on 
such a system (by having the functions contain a switch over the 
thread-local variable with the rounding mode, for example, and doing the 
same in all user code that enables FENV_ACCESS and might possibly run in 
non-default rounding modes), but it's not exactly convenient.

Essentially that would involve the reverse of what TS 18661-1 envisages 
when it gives an example of a code sequence with __swapround to implement 
constant rounding directions on a machine where the rounding mode is 
dynamic only.

(To implement the FENV_ROUND pragma, one might have the front end insert 
__builtin_feswapround calls - in which case machines with static rounding 
modes would need to reverse that to identify the rounding modes for 
particular operations - or one might have it tag the operations and a 
later lowering stage insert such calls.  That's in addition to affecting 
constants and appropriately marked function calls.)

Joseph S. Myers

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