tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Support for non-default rounding modes in the softfloat layer



Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:

> one major difference between the existing softfloat support in libc and
> compiler-rt's softfloat implementation is the (non)support for
> rounding modes. libc supports some global variables for that, which is
> of limited usefulness in a multi-threaded world. Making them fully
> thread-local on the other hand is quite expensive. A discussion with the
> responsible developer of the compiler-rt code and some LLVM folks
> resulting in the suggestion of providing an alternative set of entry
> points, where the float environment is an explicit argument, if this
> feature is really desirable. Long story short, does anyone use
> non-default rounding modes on platforms with softfloat?

I certainly don't, but pkgsrc/benchmarks/paranoia seems to check things
like this, and it seems a regression to have that do worse.

I am not sure I understand your global vs thread-local concern - the
real issue is lexical source-code scope rather than dynamic thread
context.  I would expect that non-default rounding is most used in
FORTRAN code that doesn't tend to end up in the same binary as other
floating point code.

I would lean towards having a single static value.  That's what
fpsetmode(3) and fenv.h seem to expect, and not supporting that usage
seems nonconformant:

  http://pubs.opengroup.org/onlinepubs/000095399/basedefs/fenv.h.html
  http://pubs.opengroup.org/onlinepubs/000095399/functions/fegetround.html

Attachment: pgpTTcoTB3flE.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index