I updated the second patch with a comment about the change. Also I did some research and found the IEEE conformance issues could be addressed and still use X87 FP:
http://uw714doc.sco.com/cgi-bin/info2html?(gcc.info)Disappointments&lang=en contains: * On 68000 and x86 systems, for instance, you can get paradoxical results if you test the precise values of floating point numbers. For example, you can find that a floating point value which is not a NaN is not equal to itself. This results from the fact that the floating point registers hold a few more bits of precision than fit in a `double' in memory. Compiled code moves values between memory and floating point registers at its convenience, and moving them into memory truncates them. You can partially avoid this problem by using the `-ffloat-store' option ( Optimize Options.). The -ffloat-store option store does seem to do the trick, the associated documentation is: `-ffloat-store' Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory. This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a `double' is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use `-ffloat-store' for such programs, after modifying them to store all pertinent intermediate computations into variables. But using SSE instructions instead provides better performance. Could a gatekeeper review this patch? Thanks, Doug > -----Original Message----- > From: Gilmore, Doug > Sent: Wednesday, August 08, 2012 6:26 PM > To: 'Sun Chan' > Cc: '"C. Bergström"'; 'open64-devel' > Subject: RE: [Open64-devel] Review request: fixing issues when building > the compiler as 64-bit binaries > > I forgot that I was going to add some comments in the second patch. > > I'll be sending out another version of that patch. > > Doug > > > -----Original Message----- > > From: Gilmore, Doug > > Sent: Wednesday, August 08, 2012 1:05 PM > > To: 'Sun Chan' > > Cc: "C. Bergström"; open64-devel > > Subject: RE: [Open64-devel] Review request: fixing issues when > building > > the compiler as 64-bit binaries > > > > I did some experiments over the weekend and I discovered the flaw in > my > > approach to address the differences in code generated during register > > allocation which are due to differences in FP calculations. > > > > Initially I attempted to reduce the differences in FP calculations > > using the default compilation modes when compiling 32 and 64 bit. > > This was a mistake since trying to get calculations done using the > X87 > > FP stack instructions when compiling -m32 to closely match those done > > by SSE2 instructions (-m64 default) may be a hopeless cause. > > > > I discovered over the weekend that the key change that reduces the > > differences in FP calculations was the change to build the X8664 > > compiler compiled 32-bits with "-mfpmath=sse -msse2" when using GCC. > > > > Thus the changes needed to address these issues are much simpler (the > > patches are attached). > > > > Sorry for the confusion on my part. > > > > Also I filed a bug on the issue: > > > > https://bugs.open64.net/show_bug.cgi?id=1005 > > > > Note that attached to the bug report is a script to build all 4 > > versions of the X8664 compiler. The test example is h264ref from > SPEC > > 2006. Also there is a script that can be used to build a SPEC > > benchmark with all 4 versions of the compiler and compares the > > generated assembly files. > > > > Could a gatekeeper review these changes when they have the chance? > > > > Thanks, > > > > Doug > > > -----Original Message----- > > > From: Sun Chan [mailto:sun.c...@gmail.com] > > > Sent: Saturday, August 04, 2012 2:31 PM > > > To: Gilmore, Doug > > > Cc: "C. Bergström"; open64-devel > > > Subject: Re: [Open64-devel] Review request: fixing issues when > > > building the compiler as 64-bit binaries > > > > > > my point is, even these kind of "comparison" error due to rounding > > etc > > > should not have cause your heuristics to go haywire. If your > > > heuristics is so sensitive, something else is wrong. If you can > > > illustrate with an example, that might be good. For the kind of > > > heuristics I have seen, they don't matter. > > > Sun > > > > > > On Sun, Aug 5, 2012 at 1:58 AM, Gilmore, Doug > <doug.gilm...@amd.com> > > > wrote: > > > > I was looking into other issues yesterday so I was sidetracked. > > > >> -----Original Message----- > > > >> From: Sun Chan [mailto:sun.c...@gmail.com] > > > >> Sent: Saturday, August 04, 2012 3:24 AM > > > >> To: Gilmore, Doug > > > >> Cc: "C. Bergström"; open64-devel > > > >> Subject: Re: [Open64-devel] Review request: fixing issues when > > > building > > > >> the compiler as 64-bit binaries > > > >> > > > >> I haven't had any real code segment to explain why the change to > > > float > > > >> to double is needed for the claim, i.e. enable 64bit porting, > and > > > >> better precision. I have to do this in the abstract. > > > >> I don't see any relationship between float and double to 64 bit > > > >> porting. As for precision, the example given is "probability". > For > > > >> compiler optimization, it is true that probability is widely > used > > > >> to help heuristics, but I have yet to see an example where one > > > >> needs beyond 2 decimal point precision. > > > > If actually had 2 decimal point precision float point arithmetic, > > > then > > > > you would need to be extremely careful to insure that there were > no > > > > reordering of FP operations. Otherwise there would be enough > noise > > > in > > > > the calculations to produce different FP comparison results. > > > > > > > > I am still collecting data on this. > > > > > > > > Sorry for the delay. > > > > > > > > Doug > > > >> I'm gonna have to say, this change from float to double is not > > > useful > > > >> other than making data size larger, which is in general not a > good > > > >> thing. > > > >> Sun > > > >> > > > >> On Fri, Aug 3, 2012 at 7:38 AM, Sun Chan <sun.c...@gmail.com> > > wrote: > > > >> > for the float/double issue, can you include a code snippet > that > > > will > > > >> > affect by this change (you have mentioned probability, for > > > example) > > > >> > Thx! > > > >> > Sun > > > >> >
0002-X8664-m32-FP-compilation-mode-change-when-compiling-.patch
Description: 0002-X8664-m32-FP-compilation-mode-change-when-compiling-.patch
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
