Re: Unnecessary spillage

tim@franck.Princeton.EDU (Tim Hollebeek)
Fri, 8 Sep 1995 08:19:44 GMT

          From comp.compilers

Related articles
Unnecessary spillage (Trevor Pering) (1995-09-01)
Re: Unnecessary spillage tim@franck.Princeton.EDU (1995-09-08)
| List of all articles for this month |

Newsgroups: comp.compilers
From: tim@franck.Princeton.EDU (Tim Hollebeek)
Keywords: optimize, registers
Organization: Princeton University
References: 95-09-048
Date: Fri, 8 Sep 1995 08:19:44 GMT

Trevor Pering <> wrote:
>I am working on an optimizing phase for the Sather compiler.
>( The Sather compiler compiles to ANSI
>C, and lets a C compiler finish the job off. My optimizer is
>concerned with optimizing expressions across procedure calls....
>if it can statically determine that foo() cannot in anyway change the
>result of x->y (this optimization is difficult for the compiler, if
>not impossible, because foo() may have side-effects)...

Many compilers are aware of this, and allow you to tell them this
difficult fact, so that the compiler doesn't have to determine it

Here is an excerpt from the SGI includes:
#pragma no side effects (log)

You might also want to look at the gcc 'const' attribute:
          Many functions do not examine any values except their arguments,
          and have no effects except the return value. Such a function can
          be subject to common subexpression elimination and loop
          optimization just as an arithmetic operator would be. These
          functions should be declared with the attribute `const'. For

                    int square (int) __attribute__ ((const));

          says that the hypothetical function `square' is safe to call fewer
          times than the program says.

of course, 'no side effects' is probably a bit too strong for most
uses; one is really interested in whether there are any _relevant_
side effects.

One can help the compiler out in some cases:

za = x->y;
... za ...;
... za ...;

The compiler now knows it can safely register-ize za (assuming it's
address is never taken). Generally, tho, C code generated from other
languages is tough to optimize since the 'primitives' of the language
being generated are often function calls, giving the optimizer fits,
and and the optimizer has a much harder time detecting the 'structure'
of the code as this has been lost in the conversion.

Tim Hollebeek
PChem Grad Student
Princeton University

Post a followup to this message

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