gl8f@astsun9.astro.virginia.edu (Greg Lindahl) (11/18/90)
Actually, since it turns out Dennis is reading this group, I should go do my research instead of posting, but... In article <14780:Nov1605:10:4490@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: [ after insulting gcc, claiming it can't get strength reduction correctly ] >All you wanted was real examples for real optimizers. I had thought that >you were listening when other people posted real examples. Apparently >not. Now I've posted the examples for you. And your examples are wrong. Please, before you post any more examples, check them for careless errors. I used gcc 1.37.1. >> I showed you code in which FORTRAN does well, and you have to >> hand-optimize C to beat it. > >All I meant by ``don't do very well'' is that I can easily do better in >machine language. We are, after all, talking about whether Fortran >arrays are always as efficient as pointers (as in machine language, for >instance). I didn't say anything about C. As a programmer, I want fast runtime and low coding time. I have shown you a class of problems where FORTRAN gets both, because it doesn't have the aliasing problems that C does. Even a STUPID fortran compiler can get the optimization, but the smartest C compilers don't. I can always do no worse than FORTRAN by writing in assembler, for any processer that I am competetant in assembler. But this isn't the interesting point. If you study this example, you'll see ways in which C can be changed to make it more useful for a wider class of problems. Dan then claims: >1. The compiler can do quite a bit of aliasing analysis without taking >any hints from the programmer (and respecting separate compilation). No existing C compiler does a good job on this, although Convex tries. Why? Because it's difficult, because of the lack of true arrays and aliasing. Instead of asserting the possibility that difficult problems can be solved, consider the fact that simple solutions exist. >See, here's where you simply fail to pay attention to the main points of >the thread. A sufficiently smart compiler *can* do the job for C, >without *any* hand optimization. Current compilers happen not to be that >smart. Would you please stop misrepresenting my position? Stop misrepresenting mine. No existing compiler does the necessary analysis. No compiler can do an anlysis as strict as the FORTRAN anti-aliasing requirement. See my previous postings for the example that breaks your technique. You never replied to my example. >Of course, Greg hasn't even made the effort that Jim has to contribute >to the discussion. He has completely ignored my comments on how the >compiler can optimize C array code with no help from the programmer. Actually, I showed you an example of typical FORTRAN code that illustrates how difficult it is to even come close in C. I guess you find non-local analysis easier than analysis that doesn't have to go outside of the basic block. I guess you ignored my posting explaining that current C and FORTRAN compilers from Cray already detect cases where a run-time test can detect situations where optimized code could be used. Dan Bernstein was there in spirit. And, finally, I guess you don't remember that I suggested that comparing the starting addresses of arrays could lead to significant optimizations quite a while ago -- long before I saw your (incorrect) fortran-equivalent test. And, other than flaming on comp.lang.misc, I was discussing it with the author of GNU Fortran last weekend. It should be very interesting to see how much influence GNU Fortran can have on gcc. Have a nice day, Dan, and be sure to get some work done other than giving us your perls of wisdom on comp.lang.misc. I'll be looking forward to your solution of Dennis' sorting problem.