|SPARC compiler optimisation email@example.com (1992-02-13)|
|Re: SPARC compiler optimisation firstname.lastname@example.org (1992-02-14)|
|Re: SPARC compiler optimisation email@example.com (1992-02-14)|
|Re: SPARC compiler optimisation firstname.lastname@example.org (1992-02-15)|
|Re: SPARC compiler optimisation email@example.com (1992-02-22)|
|Re: SPARC compiler optimisation firstname.lastname@example.org (1992-02-26)|
|Re: SPARC compiler optimisation email@example.com (1992-02-27)|
|Re: SPARC compiler optimisation nickh@CS.CMU.EDU (1992-02-28)|
|Re: SPARC compiler optimisation nickh@CS.CMU.EDU (1992-03-02)|
|[2 later articles]|
|From:||firstname.lastname@example.org (Dana How)|
|Organization:||DSG, Stanford University, CA 94305, USA|
|Date:||Fri, 14 Feb 92 12:00:57 GMT|
email@example.com (Greg Wilkins) writes:
>I need to generate frequent checksums on a SPARC machine, and I have
>been looking at the code the sun optimizer produces for the code:
>The best that -O4 can do is a 5 tick loop: ...
>It is possible to write a 4 tick loop (20% saving) : ...
>Looking at other code, it looks like the compiler/optimiser never
>uses the [%R+%R] addressing mode. Is there a reason for this?
You have run into my biggest complaint about the Sparc optimizer: it does
not realize that the addition in [%a+%b] is FREE and attempts to move it
outside of the loop. (I have forgotten all the accepted names for these
standard loop tricks). I would imagine this is because the optimizer
works on an expression tree well before code generation; and it simply
attempts to minimize the total number of operators inside the loop, not
realizing that in ld/st op's you get ONE for free. (yet it does this
correctly for %a+constant...). And yes, I have NEVER seen the optimizer
This is frequently a big pain for me, since i always try to write loops
where everything is indexed by one loop variable from different bases.
Frequently the optimizer will turn this into SEVERAL combined indices to
avoid the imaginary ADD instruction, and then have to maintain EACH
Return to the
Search the comp.compilers archives again.