Maciej W. Rozycki <ma...@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
