On Fri, May 08, 2015 at 01:05:59PM -0600, Jeff Law wrote: > On 05/06/2015 11:29 AM, Michael Meissner wrote: > >On Wed, May 06, 2015 at 04:03:00PM +0100, Richard Sandiford wrote: > >>Jeff Law <l...@redhat.com> writes: > >>>So my worry here is that folks writing these loops to iterate over modes > >>>are going to easily miss the != VOIDmode terminator, or not know when to > >>>use GET_MODE_WIDER_SPECIAL. > >>> > >>>We can certainly go with the patch as-is since you've done the work to > >>>sort out which GET_MODE_WIDER to use and added the appropriate > >>>termination checks. But do we want to try to future proof this a > >>>little and define two iterators for folks to use rather than write the > >>>loops by hand every time and probably getting it wrong -- and wrong in > >>>such a way that it only breaks on PPC, forcing someone to regularly be > >>>fixing this stuff > > > >If they miss the != VOIDmode, the program will hang since it will never exit > >the loop (VOIDmode is the wider type for VOIDmode). > OK. And presumably if someone is adding a new loop over the modes > they'll actually be testing that code on whatever target they're > using. So it's unlikely they'll introduce an infinite loop on other > targets by accident.
In looking over the patch, I learned a lot more about the internal mode handling. I discovered that I can use FRACTIONAL_FLOAT_MODE to add the new types (IFmode for IBM double-double with 106 fracational bits, and KFmode for IEEE 128-bit with 113 bits, and TFmode will become either of these depending on the defaults and switches). What I was missing when I previously tried to use FRACTIONAL_FLOAT_MODE is when I create these new modes, in the case where they are not active, I have to make sure that HARD_REGNO_NREGS never returns true for any register (including GPRs), and the mode will be skipped. I don't need to add the special tests against VOIDmode during the widening rules. So, I don't need any special machine independent support for adding IEEE 128-bit floating point to the compiler. Thanks for pushing me to re-investigate the changes and clean them up. During my investigation, I did come up with a FOR_EACH iterator for emit-rtl.c and a few other places that make the iteration over all modes easier, and I will clean that up and submit it as a separate patch. Some of the other mode widening places in the machine independent parts of the compiler could also be cleaned up (lto-streamer in particular), that I may or may not submit patches for. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
