Re: Finding MAC instructions

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

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