Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: Cameron McInally Newsgroups: comp.compilers Subject: Re: Compiler optimization and floating point operations Date: Mon, 28 Oct 2013 20:41:38 -0400 Organization: Compilers Central Lines: 20 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-10-039@comp.compilers> References: <13-10-026@comp.compilers> <13-10-029@comp.compilers> <13-10-037@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: leila.iecc.com 1383014845 23570 64.57.183.58 (29 Oct 2013 02:47:25 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Tue, 29 Oct 2013 02:47:25 +0000 (UTC) Keywords: optimize, arithmetic Posted-Date: 28 Oct 2013 22:47:25 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:1022 On Mon, Oct 28, 2013 at 6:50 PM, wrote: >> [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] > > Take fused multiply-add, and the expression a*b + c*d. > It can be evaluated either as fma (a, b, c*d) or fma (c, d, a*b). > > It would seem natural that the code for a*b + c*d and for c*d + a*b > would be different, with different results. Right, that's called reassociation. The order of operations in the expression tree has changed, so the finite precision rounding occurs on different intermediate results. The same problem exists in some floating point parallel reductions and such. Most compilers will offer a directive, similar to FP_CONTRACT, for such critical pieces of code. Some compilers [the good ones ;)] even have flags to disable optimization passes that involve reassociation. -Cameron