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: | spot@CS.CMU.EDU (Scott Draves) |
Keywords: | optimize |
Organization: | School of Computer Science, Carnegie Mellon University |
References: | 92-01-087 92-02-010 |
Date: | Mon, 03 Feb 92 17:48:03 GMT |
On 2 Feb 92 16:26:08 GMT, hrubin@pop.stat.purdue.edu (Herman Rubin) said:
> If one has a program of even moderate size, the number of
> branches possible will undoubtedly exceed the size of the
> universe, and even with the fastest computing procedures
> consistent with current physics (NOT engineering), the
> analysis could never be completed.
certainly true. the superoptimizer is only applicable to small code
fragments. nobody claims otherwise.
> But there is a much greater problem. It is not only necessary
> to consider rearrangements of code, but even totally different
> algorithms. I do not see how a superoptimizer just looking at
> the code could replace the usual multiplication scheme with
> any of the faster alternatives.
nf fact, this is exactly the sort of thing the superoptimizer *is* capable
of, and that is one of the things that makes it very interesting. i think
another explanation of what it does is in order: the SO searches *all*
code sequences shorter than the input sequence. it returns the shortest
one it finds that has the same semantics as the input. how it prunes the
search tree, and how it checks the semantics quickly are what make it a
non-trivial program.
--
scott draves, spot@cs.cmu.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.