This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: Make MIPS soft-fp preserve NaN payloads for NAN2008
On Thu, 5 Jan 2017, Matthew Fortune wrote:
> > > AFAIR we deliberately decided not to define a 2008-NaN soft-float
> > > ABI, and chose to require all soft-float binaries to use the legacy
> > encoding.
> >
> > Soft-float and 2008-NaN are naturally completely orthogonal and the
> > combination works fine (of course, it doesn't need any special kernel or
> > hardware support). There's no need to disallow the combination.
True, however unlike with hard-float we are not constrained by hardware
here and IMO the advantage of using 2008-NaN semantics (i.e. payload
preservation) does not outweigh the drawback of having two incompatible
ABIs and the issue of interlinking between them -- a solution for which
which, as it has been shown, causes enough controversy to still have not
been agreed upon. Why not avoid it altogether then, as originally chosen,
and stick to legacy NaN for all soft-float?
> > In any case, the soft-fp change is relevant in the hard-float case as
> > well, to make software TFmode behave consistently with hardware SFmode
> > and DFmode regarding NaN payload preservation.
Is mixing TFmode, DFmode and SFmode operations with the two latters
handled in hardware and the former deferred to soft-fp a supported
configuration? Do we have any MIPS ABI which provides for using all these
data types? AFAIK all MIPS/Linux ABIs use DFmode for `long double' and
IRIX support (which did have a TFmode data type, though used an unusual
format and didn't support 2008 NaN anyway) has been dropped. Any bare
metal targets? I dare say none of the MIPS/*BSD targets supports 2008
NaN; no idea offhand about their TFmode support.
> It is true to say that users are discouraged from using 2008-NaN with
> soft-float for pre-R6 architectures simply to avoid further fragmentation
> of software for no real gain. However, for R6 then soft-float is 2008-NaN
> otherwise we are stuck with legacy-NaN forever.
What's the actual issue you have with legacy NaN, and how does soft-float
relate to R6? It's not like hardware, R6 or othwerwise, limits soft-float
in any way.
> If someone did want to build a system from source with soft-float as
> 2008-NaN then I see no reason to stop them but I doubt they would and I
> don't expect the --with-nan GCC configure option to be used in conjunction
> with --with-float=soft for the same reason. The most likely use of
> --with-nan is to build a distribution specifically to target an MSA capable
> system like P5600 or perhaps an M5150 with an FPU. The NaN interlinking
> work will make these use-cases less important still though I think.
You can have GCC configured with `--with-nan=2008' and equipped with a
soft-float multilib. IMHO you ought to be able to just use `-msoft-float'
then to select the soft-float multilib and have it implicitly use the
legacy NaN encoding rather than having to pass `-msoft-float -mnan=legacy'
to get the intended semantics.
There shouldn't be a need for NaN interlinking for soft-float objects,
that's just unnecessary burden IMO.
MSA is irrelevant for soft-float operations, we don't have a soft-float
MSA ABI. If we ever define one, then we could well choose the 2008-NaN
encoding for compatibility with hard-float code; there's no issue with
backwards compatibility here as no legacy-NaN MSA hardware has been ever
allowed.
Have I missed anything?
Maciej