Re: Finding MAC instructions

henry@spsystems.net (Henry Spencer)
23 Jul 2006 16:19:07 -0400

          From comp.compilers

Related articles
Finding MAC instructions plfriko@yahoo.de (Christian Christmann) (2006-07-16)
Re: Finding MAC instructions emailamit@gmail.com (Amit Gupta) (2006-07-18)
Re: Finding MAC instructions jeffrey.kenton@comcast.net (Jeff Kenton) (2006-07-22)
Re: Finding MAC instructions henry@spsystems.net (2006-07-23)
| List of all articles for this month |

From: henry@spsystems.net (Henry Spencer)
Newsgroups: comp.compilers
Date: 23 Jul 2006 16:19:07 -0400
Organization: SP Systems, Toronto, Canada
References: 06-07-019 06-07-033
Keywords: optimize, arithmetic
Posted-Date: 23 Jul 2006 16:19:07 EDT

Amit Gupta <emailamit@gmail.com> wrote:
>A naive (but useful) preprocessing step would be to greedily select
>obvious mac operations. This is easier done at high-level language
>flow graph before it is converted to IR representation. The useful
>thing is here is, you can catch the designer intent...


A general observation: programmers strongly prefer *predictability* in
such things, especially in floating-point representations, where
overly- enthusiastic expression restructuring can totally ruin code
that was carefully designed to have good rounding properties.


A float MAC, which usually does only one rounding rather than two, is
very much a two-edged sword: it can be a very useful tool, but it can
also make devastating messes. For example, multiplying a complex
number by its conjugate mathematically gives a real -- the imaginary
part is exactly zero -- and that is also true of IEEE floating-point
arithmetic... provided FMAC is *NOT* used in ways that mess up the
symmetry of the expressions. Yes, doing fewer roundings can worsen
rounding errors!


(This is an example of a general floating-point principle:
intermediate results are often correlated with each other in subtle
ways that are important to good results. Optimizations which can
disrupt such correlations are dangerous, even if, in isolation, it
might seem that they should improve the error properties of the code.)


If the compiler is going to try hard to find places where a MAC can be
used, there must be a way to tell it "hands off" for carefully-crafted
code, *without* disabling other important optimizations.


Similarly, there should be a way to tell the compiler that it *must*
use a MAC in this particular expression, and it should warn you if
it's unable to do so. People who want to do this are likely to care
very much about speed, and so they can't just call a library function
(unless the compiler is *required* to inline it).
--
spsystems.net is temporarily off the air; | Henry Spencer
mail to henry at zoo.utoronto.ca instead. | henry@spsystems.net



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.