home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.lang.c:13188 comp.sys.sun.misc:4076
- Path: sparky!uunet!cs.utexas.edu!sun-barr!rutgers!concert!aurs01!throop
- From: throop@aurs01.UUCP (Wayne Throop)
- Newsgroups: comp.lang.c,comp.sys.sun.misc
- Subject: Re: sun cc optimization failure
- Summary: deficient optimizer technology
- Message-ID: <61124@aurs01.UUCP>
- Date: 3 Sep 92 19:12:20 GMT
- References: <1992Sep3.040401.16902@mr.med.ge.com> <880@metrix.UUCP>
- Sender: news@aurs01.UUCP
- Reply-To: throop@aurw44.aur.alcatel.com.UUCP (Wayne Throop)
- Organization: Alcatel Network Systems, Raleigh NC
- Lines: 61
-
- - #include <stdio.h>
- ->> main() {
- ->> int i,j,ax;
- ->> ax = 0;
- ->> for(i=0;i<3;i++){
- ->> j = ax * i;
- ->> puts("in for loop");
- ->> }
- - return 0;
- ->> }
- ->> when compiled with cc (sun os 4.1 on sparc 1+), the
- ->> code runs thru the loop three times. when comiled with
- ->> the -O flag it only runs once.
- -> If you look at the assembler output of the compiler using the following
-
- Out of curiosity, I ran this through the three compilers I had
- available for the MIPS architecture (decstation) machine I have here.
- The two MIPS-based compilers (classic and ansi C) both optimized
- the loop to be
-
- move $16, $0
- la $17, $$50
- li $18, 3
- $32:
- move $4, $17
- jal puts
- addu $16, $16, 1
- bne $16, $18, $32
-
- The gcc 1.39 mumble-whatever version I have made it
-
- move $16,$0
- $L5:
- subu $sp,$sp,16
- la $4,$LC0
- jal puts
- addu $sp,$sp,16
- addu $16,$16,1
- ble $16,2,$L5
-
- In general, this older gcc does significantly more frame-and-stack
- pointer twiddling, both in this loop and in the prolog and postlog
- code and the like, compared to the MIPS-based compilers.
- (2.0 may do better.)
-
- But the thing that struck me was, why didn't the optimizer just
-
- la $4,$LABEL
- jal puts
- jal puts
- jal puts
-
- (or some variation on this theme) as it "should" have?
-
- ( Maybe there are RISCish slot-filling considerations that prevent it...
- but I really think the compilers just don't do simple loop unrolling,
- even when they've already demolished the innards of the loop anyhows. )
-
- Just another of the many things that make me go "Hmmmmmm."
-
- Wayne Throop ...!mcnc!aurgate!throop
-