Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!ico!haddock!ima!esegue!compilers-sender
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.compilers
Subject: Re: SLO too slow?
Keywords: optimize
Message-ID: <2690@dataio.Data-IO.COM>
Date: 6 Sep 90 01:46:11 GMT
References: <9009031649.AA02942@nero.cs.montana.edu>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 30
Approved: compilers@esegue.segue.boston.ma.us

In article <9009031649.AA02942@nero.cs.montana.edu> icsu8209@nero.cs.montana.edu (Glassy) writes:
<The idea, of course, is a portable optimiser.  Code improvements like CSE,
<code motion, and strength reduction should (I wonder) be possible to perform
<at the source level, instead of only at the IR level (which is what seems
<most common).

The approach I'd use (which I've seen done successfully) is to optimize the
IR. Translate the IR back into C for the output file. The translation is
usually pretty simple.

The reason the project I knew about did this was in an attempt to write a
debugger for optimized code. It also made for great ease in debugging the
optimizer!

My optimizer (Zortech's) when compiled in debug mode, can dump its output
in C. This makes it much easier to debug...

<(I know real cases exist where declaring something as 'register' yields 300%
<speedup...

The optimizer determines register candidates, and sorts them in order of
desirability of actually stuffing them into registers. The code generator
does the stuffing. The C output would just see the declarations with
'register' in front of them, sorted from most desirable to least desirable.

You can even do coloring this way, simply name the variables that color
into the same register with the same name!
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.