RE: [RFC, MIPS] Relax NaN rules
Maciej W. Rozycki 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
Re: [RFC, MIPS] Relax NaN rules
Matthew Fortune writes: > Maciej W. Rozycki 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. Ah, OK. > 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. The problem with a third mode is that, as discussed upthread, there's no way in general to tell whether a given bit of code cares about sNaNs or not. So the third mode is really just an assertion by the user that NaN encodings don't matter. I think in that case a separate mode is only useful if: (a) the entire single-variant base system is built in don't-care mode (a bit like it would be built with -mfpxx, which is what makes -mfpxx useful). But is it really feasible for the system to be completely agnostic about the NaN encoding? I assume any long double emulation code (if using the normal form of n32/64) and any float parsing code would then need to look at the FCSR before generating a NaN. NaNs in C initialisers would be disallowed. Etc. These are rules that would need to be followed throughout the codebase, even the target-independent parts. Would a portable codebase really be willing to accept that for a MIPS oddity? If instead some routines in some system libraries assume a particular NaN encoding but the library binaries themselves claim to be "don't care" (on the basis that everything is OK if you avoid those routines) then we lose the ability to say that using a "don't care" library will not in itself cause your application to depend on NaN encodings. And at that point any automatic rules based on the library-level markup lose their value. Also, without a guarantee like that, it becomes very hard for a user to know whether they will be affected by that encoding or not. and (b) the user has to explicitly say that they don't care, rather than it being implied by things like -mmsa. I think you wanted it the other way around, with "don't care" being the default and the user having to say explicitly that they care. Otherwise, all the third mode does is cause the system to reject any binary that is careful enough to say that it wants one encoding over another and relies on no feature that would stop it running on the processor otherwise. (This excludes MSA-only binaries, for example, since they would be rejected on non-MSA systems anyway.) Without (a) and (b) it seems like a lot of complication for a very narrow use case. If we have a system built for one encoding and a processor that uses another then in some ways... > 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. ...this seems more honest about what we're actually doing. It's also an awful lot simpler. Thanks, Richard
Re: GCC 4.9.0 Status Report (2014-03-13)
On 22 March 2014 12:18, Klaus Rudolph wrote: > I want to ask how I can find the bugs in bugzilla which are listed in > the "Quality Data" Table. It feels that there are more bugs which are > not listed. For example: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57694 That's a bug in 4.8 too, not a 4.9 regression. There are hundreds of open bugs not listed in the 4.9.0 status report. > Actually the compiler returns "not implemented" while compiling the > given example code but it seems that this bug is not tracked in the > actual quality data. > > my question is: > Which is the selection criteria that a bug is related to the release. Search for 4.9 Regression in the subject. There are links to run that search from the status section of the http://gcc.gnu.org front page. > What is maybe the missing information in a bug report to add the bug to > that list. If it's not a regression then it doesn't belong in the list.
gcc-4.9-20140323 is now available
Snapshot gcc-4.9-20140323 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140323/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 208775 You'll find: gcc-4.9-20140323.tar.bz2 Complete GCC MD5=4413a5866c24d7bb2e85cdb80eabb8e8 SHA1=7daea9a5179d63e588e607b49a0389770b45508c Diffs from 4.9-20140316 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > > Yes. The configurations that support -mno-float have separate -mno-float > multilibs. In a sense, the point of -mno-float instead of -msoft-float is > to select these cut-down libraries. IIRC, glibc loads some code on demand to achieve the goal of reducing the size of what is on memory. This does not require compiling the code in a special way. > > > > I don't know how exactly that would work. You would switch twice for > > each function and ask the register used for each function call? > > Yeah, that's the idea. More generally, run initialize_argument_information > once for each ABI and compare the two arg_data arrays. Similarly for > function.c. It does not work with the pcs attribute though. When the attribute is set for a function, the default ABI is ignored and the one specified in the attribute is used instead. So even if you created 2 sub-targets (I hope it's the right term), the two calls to initialize_argument_information would return the same register for a float argument even since the attribute is used instead and you would miss the fact that the function might be float ABI dependent. FYI, such a flag is used for some libgcc functions: __fixdfi __fixsfdi __fixunssfdi __fixunsdfdi Also as you said, calling twice initialize_argument_information for each function call might be suboptimal, although that ought to be benchmarked. Therefore I believe a new hook is necessary. For opted for a variable set by the backend whenever a function is float ABI dep but it is not a very elegant approach: the hook is very specific to this use case and uses a variable to communicate back and forth between backend and middleend. Thus I am open to suggestions for a better hook. Can a reverse hook be used (backend calling a function in middle end) by the way? Best regards, Thomas
Re: [RL78] Questions about code-generation
On 03/22/14 05:29, Richard Hulme wrote:
On 22/03/14 01:47, Jeff Law wrote:
On 03/21/14 18:35, DJ Delorie wrote:
I've found that "removing uneeded moves through registers" is
something gcc does poorly in the post-reload optimizers. I've written
my own on some occasions (for rl78 too). Perhaps this is a good
starting point to look at?
much needless copying, which strengthens my suspicion that it's
something in the RL78 backend that needs 'tweaking'.
Of course it is, I've said that before I think. The RL78 uses a
virtual model until reload, then converts each virtual instructions
into multiple real instructions, then optimizes the result. This is
going to be worse than if the real model had been used throughout
(like arm or x86), but in this case, the real model *can't* be used
throughout, because gcc can't understand it well enough to get through
regalloc and reload. The RL78 is just to "weird" to be modelled
as-is.
I keep hoping that gcc's own post-reload optimizers would do a better
job, though. Combine should be able to combine, for example, the "mov
r8,ax; cmp r8,#4" types of insns together.
The virtual register file was the only way I could see to make RL78
work. I can't recall the details, but when you described the situation
to me the virtual register file was the only way I could see to make the
RL78 work in the IRA+reload world.
What would be quite interesting to try would be to continue to use the
virtualized register set, but instead use the IRA+LRA path. Presumably
that wouldn't be terribly hard to try and there's a reasonable chance
that'll improve the code in a noticeable way.
Looking at how that's done by other backends, as far as I can tell, I
just need to add something like:
#undef TARGET_LRA_P
#define TARGET_LRA_P rl78_enable_lra
static bool
rl78_enable_lra (void)
{
return true;
}
to rl78.c? At least in theory, even if other work is needed elsewhere
to make things run smoothly.
Unfortunately, that function never seems to be called.
How does TARGET_LRA_P get used, anyway? I can't find anything that
tries to use it, only places where it gets set. Is there some funky
preprocessor stuff going on that's stopping me grepping for it?
That should be enough to switch to the LRA path. It's a target hook.
Grep for "targetm.lra_p"
Jeff
Re: [RL78] Questions about code-generation
On 03/22/14 05:38, Richard Hulme wrote: Can you explain what is too weird about it in particular? It certainly has restrictions on which registers can be used with various instructions but I wouldn't have thought they were that complicated that they couldn't be described using the normal constraints? Register banks come to mind. Also look at addressing modes and instructions which require using specific registers.Also look at insns which may exhaust the register file. All those tend to be problematical. jeff
