lvc@danews.UUCP (04/07/87)
I'm all for optimization but ... There is a certain computer (that I still use) that requires the statement: n = n; in order to force the hardware to work right for certain values of n. Well fix the **** computer you say, and so do I. But that will be a while and I can't wait. If I had an optimizing compiler that was smart (?$!?) enough to excise this I couldn't make the machine work right. Please dear compiler writers, make the compiler do what I tell it (or at least have the courtesy to warn me about it). If hardware was perfect then I wouldn't have a gripe, but it ain't so I do. -- Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999
guy@gorodish.UUCP (04/07/87)
>Please dear compiler writers, make the compiler do what I >tell it (or at least have the courtesy to warn me about it). >If hardware was perfect then I wouldn't have a gripe, but >it ain't so I do. That's a nice general request, and as such nearly useless. What does "do what I tell it" mean? To what level of detail are you "telling it"? Do you think moving invariant computations out of loops is not "doing what you tell it"? What about strength reductions? What about eliminating assignments to dead variables? Compiler writers simply can't anticipate every single potential hardware problem that may crop up and that may require you to put in code that is in principle redundant.
rpw3@amdcad.UUCP (04/08/87)
In article <479@danews.ATT.COM> lvc@danews.ATT.COM (Larry Cipriani) writes: +--------------- | There is a certain computer (that I still use) that requires the statement: | n = n; | in order to force the hardware to work right for certain values of n... | If I had an optimizing compiler that was smart (?$!?) enough to excise this | I couldn't make the machine work right. +--------------- I can't agree. Instead, *tell* the compiler that you need to do this. In ANSI C (or any useful optimizing C compiler), simply say: volatile int n; ... n = n; And the compiler will *always* fetch & store "n" when referenced. Rob Warnock Systems Architecture Consultant UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3 ATTmail: !rpw3 DDD: (415)572-2607 USPS: 627 26th Ave, San Mateo, CA 94403
lvc@danews.UUCP (04/08/87)
In article <16294@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: >That's a nice general request, and as such nearly useless. What does >"do what I tell it" mean? To what level of detail are you "telling >it"? Do you think moving invariant computations out of loops is not "doing what you tell it"? What about strength reductions? What >about eliminating assignments to dead variables? > >Compiler writers simply can't anticipate every single potential >hardware problem that may crop up and that may require you to put in >code that is in principle redundant. Thanks for your comments. Your points are well taken. I guess I meant at the "source code level" but I see that isn't very useful. My preference is for a program (perhaps a phase of an optimizing compiler) that would take source code and generate optimized *source* code. Additionally, messages saying why the transformations are better would be great to have. I believe such programs are available for Fortran (or do these concentrate on vectorization) but I've never seen one for C. I want to be able to use assembly language debuggers and follow a *source* listing that I have in front of me on my desk. Then I would not mind if the optimizer did all these things. Granted some optimizations occur at the assembly language level, but those wouldn't affect my ability to follow the code very much. What is strength reduction? -- Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999
stevev@tekchips.UUCP (04/09/87)
In article <484@danews.ATT.COM>, lvc@danews.ATT.COM (Larry Cipriani) writes: > My preference is for a program (perhaps a phase of an optimizing > compiler) that would take source code and generate optimized *source* > code. Additionally, messages saying why the transformations are > better would be great to have. I believe such programs are available > for Fortran (or do these concentrate on vectorization) but I've never > seen one for C. Even thought a source level "optimization" is machine-independent in that its legality does not depend on the architecture, whether any particular optimization will improve the quality of the code cannot be known unless you know something about the architecture. The types of source-level optimizations done for a parallel architecture might be quite different than for a traditional uniprocessor. An example of an "optimization" that could turn out to decrease code quality is that of common subexpression elimination. The save the value of the common subexpression requires the allocation of an extra register. It's possible that the negative effect of tying up the extra register more than cancels that which is gained by eliminating the redundant computation. You need information about the particular architecture you are targetting in order to make this decision. Another example: I programmed on an architecture once in which the fastest way to produce certain constants--due to the archicture's addressing modes-- was to "unfold" the constant into two simpler ones (e.g., 1072 becomes "134 lsh 3"). Thus, even constant folding is not necessarily always the optimal thing to do. A microarchitecture that I was marginally familiar with has such a fast multiplier that the fastest way to perform a shift of more than some very small number of bits was to transform into an equivalent multiplication by a power of two. On such an architecture, a strength reduction that transforms a multiplication into a shift might DECREASE code quality. All this aside, IF you have a pretty good idea what kind of architecture you're targetting, source-level optimization can generally be quite effective. Steve Vegdahl Computer Research Lab Tektronix Labs Beaverton, Oregon
jfh@killer.UUCP (04/09/87)
The request seems fairly obvious to me. One writer wrote about how his line n = n; was necasary for the hardware to work. I have seen compilers drop that one on the floor. There was also some discussion about adding a new storage class to C named 'volatile' or some so that references of this seemingly weird type aren't ignored. The device driver code for some hardware requires you to read from a silo more than one time to get the desired peice of information. If I write status = *silo; status = *silo; on a real *smart* compiler, the second assignment may never happen. I might get real clever and write status = *silo; status = 0; status = *silo; only to find the first two lines dropped. If I am stupid enough to write n = n; The compiler should be smart enough to code the turkey. Compilers are for compiling, program verifiers are for 'picking the peices of fluff' from your programs. - John. Disclaimer: I hold you entirely responsible for what I write.
jimp@cognos.uucp (Jim Patterson) (04/10/87)
In article <479@danews.ATT.COM> lvc@danews.UUCP writes: >There is a certain computer (that I still use) that >requires the statement: > > n = n; > >in order to force the hardware to work right for certain >values of n. >If I had an optimizing compiler that was smart (?$!?) >enough to excise this I couldn't make the machine work >right. I suggest that the compiler should do more - it should perform its calculations so that the necessary operations (e.g. "n = n") are done automatically, as necessary, to ensure that the results are correct. If I am porting software to this certain computer, I certainly would not want to go into the code and insert dummy assignments wherever necessary (wherever that is) just to make otherwise valid algorithms work. This is a task that the compiler should do for me. Otherwise, it is not correctly implementing the abstract machine model for the C language. Conversely, if I am using a machine where these dummy assignments aren't necessary, then I don't care if the compiler removes them except that in general I want the code to run as fast as possible, but correctly of course. C is a (reasonably) portable language for sofware development. As such, it depends on an abstract machine model to define its operations. The role of any C compiler is to implement that model as closely as is possible. To this end, it should not do any optimizations that comprimise its conformance to the model. Hence, on your computer it should not likely optimize out "n = n" if it may affect the results of an operation (unless it otherwise guarantees that "n" is properly represented, which I think is the preferrable approach). Conversely, any optimizations it can do which DO NOT ALTER the results that are predicted by the abstract model can reasonably be performed.