Re: Effectiveness of compilers today

lindsay+@cs.cmu.edu (Donald Lindsay) writes:


>I maintained just such a beast (written by Guy Steele).
>It didn't search for ways to multiply by N. instead, it generated all
>interesting combinations of the relevant instructions (up to some code
>size that would be as slow as the general method). For each, it found out
>*what* N that was equivalent to multiplying by. If the code combination
>was better than the previous-best (for N), then, write it down.


>This code ran for days, but on a VAX 11/780. A 70-SPECint machine should
>be able to do things like this in an afternoon.


I've done it too, almost exactly as you describe, but on a 70-SPECint
machine. I got a lot pretty quickly, but then the pipeline dries up.
After a few days, it keeps crunching, but new facts come very slowly.


Of course, I didn't have a limit set; I was just trying to beat a
non-optimal converter. It might be more useful if I had been trying to
beat a multiply instruction (say, one that required < 10 cycles). Without
that limit, we're going to be a long time looking for the optimal program
to compute y*1234567890 (it's maybe 17 cycles, assuming a barrel shifter,
so assume something like O(n^17) time, where n is on the order of 10).


On the other hand, Guy Steele is a smart man and may have been able to
significantly trim the search in ways I didn't realize.


Preston Briggs
--

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