Related articles |
---|
Any further work on superoptimizer? mark@hubcap.clemson.edu (1992-01-22) |
Re: Any further work on superoptimizer? chased@rbbb.Eng.Sun.COM (1992-01-23) |
Re: Any further work on superoptimizer? megatest!djones@decwrl.dec.com (1992-01-29) |
Re: Any further work on superoptimizer? hrubin@pop.stat.purdue.edu (1992-02-02) |
Re: Any further work on superoptimizer? rmf@chopin.cs.columbia.edu (1992-02-03) |
Re: Any further work on superoptimizer? spot@CS.CMU.EDU (1992-02-03) |
Re: Any further work on superoptimizer? mfx@cs.tu-berlin.de (1992-02-04) |
Re: Any further work on superoptimizer? array!colin (1992-02-09) |
Re: Any further work on superoptimizer? megatest!djones@decwrl.dec.com (1992-02-26) |
Newsgroups: | comp.compilers |
From: | rmf@chopin.cs.columbia.edu (Robert M. Fuhrer) |
Keywords: | optimize |
Organization: | Compilers Central |
References: | 92-01-087 92-01-117 |
Date: | Mon, 3 Feb 92 10:14:30 EST |
If memory serves me, the super-optimizer did its work by representing the
effect of each instruction in some encoded form (roughly Boolean). This
form worked well for some instructions and would "explode" for others. As
a result, the set of instructions it would use in building the
super-sequences was a subset of the machine's capabilities. I wouldn't be
surprised that someone could then code up a shorter sequence using
instructions not covered by the original optimizer. However, unless there
was a bug in Henry's implementation, I don't see how one could do better
if you kept yourself restricted to the same subset. The search was
*exhaustive*.
--
Robert M. Fuhrer, Computer Science Department, Columbia University
1117B Fairchild Building
Internet: rmf@cs.columbia.edu, UUCP: ...!rutgers!cs.columbia.edu!rmf
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.