On Tue, Sep 23, 2014 at 7:13 PM, Joseph S. Myers <jos...@codesourcery.com> wrote:
>> Joseph, is there any support for underflow control in soft-fp library? >> >From a private correspondence with FX about implementing gfortran IEEE >> support for extended modes, soft-fp that implements 128bit support on >> x86 could read this setting from FPU control registers and handle >> denormals accordingly. > > My current series of soft-fp patches pending review on libc-alpha includes > one for control of handling of *input* subnormals > <https://sourceware.org/ml/libc-alpha/2014-09/msg00488.html>, because that > feature is in the kernel version (and David Miller volunteered to help get > the Linux kernel using the current version of soft-fp, given the features > from the kernel version added to it > <https://sourceware.org/ml/libc-alpha/2013-10/msg00347.html>). > > As in the kernel version, that implementation sets the denormal operand > exception in this case, although it appears SSE does not do that (so > further conditioning would need to be added for this to be an accurate x86 > emulation; different architectures do different things in this case). > > Neither version has anything to control underflow on *output*. A > flush-to-zero mode as on x86 appears to be different in directed rounding > modes from abruptUnderflow as defined in IEEE 754-2008 (flush-to-zero > always produces zero, abruptUnderflow can produce the smallest normal > result depending on the rounding mode). Such flush-to-zero or > abruptUnderflow control could of course be implemented; there might be a > need for further conditions on whether the underflow and inexact exception > flags are set on flushing to zero (again, there are architecture > variations). > > (Note that such underflow control on output, at least in the architecture > manuals I checked, means underflow when the architecture-specific tininess > condition is met - not when the rounding result ends up subnormal - so > it's not possible to implement it with a late check of the rounded result; > soft-fp would need to check at the point where it decides whether the > result is tiny.) > > I don't know whether you'd want flush-to-zero emulating architecture > semantics, abruptUnderflow, or both. Looking at the standard at [1], the mode is flush-to-zero on output, which fits SSE as well. > (When used on x86 for operations involving binary128, there's also the > point that only SSE not x87 has such modes, so you'd need to consider when > it's correct to apply them to binary128 operations - is it appropriate for > conversions between TFmode and XFmode or not? Of course applying to all > operations is easiest and avoids needing the soft-fp conditionals to > depend on the operation / types involved, or having different > sfp-machine.h definitions used in different source files.) [1] http://j3-fortran.org/doc/year/03/03-131r1.txt Uros.
