This is the mail archive of the gcc@gcc.gnu.org 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: [RFC, MIPS] Relax NaN rules


Maciej W. Rozycki <macro@codesourcery.com> writes:
> On Sat, 22 Mar 2014, Richard Sandiford wrote:
> 
> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
> > > supported as it would take a lot of effort to determine when code
> > > does and does not care, you rightly point out more cases to deal
> > > with too. I'm not sure if the benefit would then be worth it or not
> > > as there would still be modules which do and do not care about old
> > > and new NaNs so it doesn't really relieve any pressure on toolchains
> > > or linux distributions. The second part of the proposal is more
> > > interesting/useful as it is saying I don't care about the impact of
> > > getting NaN encoding wrong and a tools vendor/linux distribution
> > > then gets to make that choice. Any comments on that aspect?
> >
> > Maybe it's just me, but I don't understand your use case for (2).
> > If 99% of users don't care about the different NaN encodings then why
> > would they use a different -mnan setting from the default?

MSA requires nan2008. The use case for (2) is getting MSA used in any of the
pre-built or carefully controlled linux distributions that cannot tolerate
multilib style root file systems and do not accept new built variants easily.
(All the topics I am currently working on are about removing the need for
multilibs to make use of new architecture features, the origin of O32 FR
interlinking is MSA requiring FP64).

> > Are you worried about potential future processors that only support
> > 2008 NaNs?  If so, then (a) you give good reasons why that seems like
> > a misfeature and (b) I think we should instead tackle it by continuing
> > to allow both -mnan settings for all processors.  I.e. we simply
> > wouldn't add any logic to check "is this processor/architecture
> > compatible with this encoding?".
> 
>  Such processors already exist I believe.  Matthew will fill you in on
> the details, but IIRC they are strapped at boot to either NaN mode that
> cannot be switched at the run time, i.e. via CP1.FCSR (the NAN2008 bit
> is fixed at 0 or 1 depending on the boot mode selected).

The 'proaptiv' is the only core I am aware of that has both modes in hardware,
I'm afraid I don't know whether this is boot time only or runtime configurable
I have heard both and don't remember what is actually in the core.

> Of course that
> means they can still run legacy NaN code if strapped for the legacy NaN
> mode, but it's up to the SOC/board hardware designer to decide which
> mode to choose and we have no control over that.

Indeed and this could pose a problem for the pre-built distros as described
earlier depending on how the nan rules are implemented.

> 
>  I feel uneasy about silently producing wrong results, even if it's only
> such a border case as for many the NaN is.  Perhaps switching the kernel
> into a full FP emulation mode for programs that have an unsupported NaN
> requirement would be an option?

The issue here is that pre-existing binary distros are nan1985 which would
mean crippling the performance of the latest cores.

> That should be doable with a reasonable
> effort and wouldn't affect programs that do not use the FPU at all, so
> no need to rush rebuilding everything, just the FP-intensive software
> packages.

This unfortunately still leaves us with a necessity to have new build
variants which although not impossible is also not likely to happen in
any sensible time frame. The compiler/tools engineer in me completely
agrees with the position that nan encoding differences should be accounted
for but there are scenarios that the cost of doing this outweighs the
benefits I think.

A couple of ideas to address some of the various concerns:

1) As per my original proposal of allowing the tools to be built in a mode
   that ignores nan encoding... but add a special symbol introduced by
   the linker which the fenv code could use to warn when enabling exceptions
   that could trigger incorrectly.
2) Allow MSA to be built with nan1985 even though the hardware will always
   require nan2008. (This is really just another way of masking the problem
   but is possibly even less safe as the objects would have no record of the
   'correct' encoding requirement.

Please bear in mind that I am only trying to create a build option that
vendors can use if that is the only alternative available to them. There are
environments that can cope better with the nan encoding checking although
even those environments would benefit from being able to mark objects as
nan-independent (gnu_attributes would have worked well for this). The easiest
example of something that could cope better would be an RTOS where the RTOS
itself shouldn't have to be built twice for nan encoding but the user tasks
could easily be built using a consistent nan encoding.

Regards,
Matthew


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