Path: utzoo!attcan!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.arch Subject: Re: m88000 benchmarks (and C vs ASM Message-ID: <4081@cbmvax.UUCP> Date: 22 Jun 88 17:11:09 GMT References: <2434@winchester.mips.COM> <28200167@urbsdc> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 31 In article <28200167@urbsdc> aglew@urbsdc.Urbana.Gould.COM writes: >>The problem with writing a scheduler is finding an efficient (read: heuristic) >>method of traversing the code graph. The simplest method produces the best code >>at exponential compilation time: try every possible sequence. The grief is >>trying to find a linear to quadratic time method which still gives a good >>sequence. >Do any compilers contain the simple, brute-force, exponential algorithm, >to be turned on when you are willing to spend the time, or when the graph >for a procedure is small enough? > There was a paper, an ASPLOS back, on "Super-Optimizer", a brute force >searcher. It might be nice to have that in your toolbox... It certainly wouldn't be hard. You'd want to limit it to simple graphs for obvious reasons, since it can get out of control pretty fast. However, in a properly designed version, the only limit would be how much VM you have, and how long you're willing to wait. You only need this sort of optimization for final production code, anyway. I think (if I remember correctly) that the Gross, et al, methods run in O(n^4) time, which is a lot better than the brute force method, at least for blocks bigger than 10 or 15 instructions. However, there are a LOT of small (< 20) instruction blocks for which brute force can make sense. However, for the really big blocks you see sometimes (especially from certain types of numerical/FORTRAN/bad/bizarre code), even O(n^4) is painful. There are faster (O(n^2)) methods, that produce less optimum code, but LOTS faster. Or you might try breaking the large blocks into some minimum block size artificially, so n doesn't get so big. Randell Jesup, Commodore Engineering {uunet|rutgers|ihnp4|allegra}!cbmvax!jesup