Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!rutgers!cs.utexas.edu!rice!titan!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Message-ID: <4467@brazos.Rice.edu> Date: 2 Feb 90 03:10:34 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <4466@brazos.Rice.edu> Sender: root@rice.edu Organization: Rice University, Houston Lines: 50 In article <4466@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: >In article >> for s[] over c[*,], ronly h[] over a[*,] >> for p over s[*], ronly v[] over b[,*] >> p = h innerprod v >> >> (ronly h[]) innerprod (ronly v[]) is >> let fast d initially 0 >> for fast ronly h_i over h[*], fast ronly v_j over v[*] >> d += h_i*v_j; >> return d >If you'd throw out the "ronly" and "fast" hints, I'd say these >forms aren't too bad. Why do you need to say "ronly" when it's >fairly obvious to the compiler that h and h_i are not assigned? Following up my own posting, ... I'd like a compiler to make code to make the computer do what I want. Unfortunately, it can't read minds, so I have to write a program to give it a hint. Since it's so stupid, I have to be fairly specific about how it's to do things like multiplying matrices. On the other hand, an optimizing compiling allows me to avoid too much tedium. Strength reducers are good enough that I don't need to mess with pointer variables. Various forms of redundancy elimination are good enough that I needn't bother about every little common subexpression. Vectorizers are good enough so that I need not manually insert vector primitives. Register allocators are good enough that I need not scatter register declarations about. Constant propagation is strong enough so that I can afford to declare some constants in convenient places, without bothering about folding every constant expression by hand. And all these optimizations work exceptionally well on the inner loops that consume so much time. The optimizer is written once, by the compiler writer. I, on the other hand, write many programs and I'm able to take advantage of the optimizer in all my programs. It costs compile time, but it's cheaper to use the computer to optimize my code than to do it by hand. Optimizers can't do everything. They don't parallelize Fortran very well, for example. A better language would probably be a good alternative. But why should we do what the computer can do well? Preston Briggs preston@titan.rice.edu