Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: Compiler optimization and floating point operations Date: Thu, 24 Oct 2013 07:41:12 -0400 Organization: A noiseless patient Spider Lines: 50 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-10-029@comp.compilers> References: <13-10-026@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1382619468 51990 64.57.183.58 (24 Oct 2013 12:57:48 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 24 Oct 2013 12:57:48 +0000 (UTC) Keywords: arithmetic, optimize Posted-Date: 24 Oct 2013 08:57:48 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1012 On Wed, 23 Oct 2013 13:47:10 -0700 (PDT), Abid wrote: >Does back end compiler optimizations affect the floating point >accuracy? As John said, the answer is "sometimes". FP hardware registers usually are wider than are the compiler's memory storage formats (most often 32 and 64 bit IEEE). The registers typically carry a few to several extra bits of precision which are lost when the value is stored to memory and then reloaded. For maximum precision you want to keep intermediate values in registers as much as possible, minimizing stores to and reloads from memory. For maximum consistency of results - across compiler modes or different FPUs - you generally must do the opposite: aggressively store and reload intermediate results before using them. [On many machines, clipping intermediate values can be done by moving them to and from an integer register without actually going all the way to memory. But however it is done, it slows the calculation.] Floating point operations, in general, are not commutative: changing the order of evaluation of sub-expressions can change the results. Substitutions using mathematical equivalences can change the results because floating point numbers are only an approximation of real numbers - many real equivalences don't hold for FP math. Using different FPUs may yield different results. From the back end POV this is important if there are multiple different hardware units to choose from. E.g., on the x86, the x87 FPU and the SIMD FPU have different register widths and some corresponding instructions round results differently. It is safe to do unrelated calculations on either unit, but you have to be extremely careful about using both to work on different parts of the same calculation. >Is there any research work in this area? There has been quite a lot of work aimed at improving FP in the middle (in the IR), but I'm not aware of any research specifically targeting the back end. George [I think you mean they're not associative. I don't know any situations where a+b != b+a, but lots where a+(b+c) != (a+b)+c -John]