Re: Any further work on superoptimizer?

spot@CS.CMU.EDU (Scott Draves)
Mon, 03 Feb 92 17:48:03 GMT

          From comp.compilers

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)
| List of all articles for this month |
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
--


Post a followup to this message

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