This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gcc loop unrolling problem ??


Thanks, but this is not my function. It is a testcase in the gcc.c-torture
-> 990801-1.c 

Kon ??
"The answer is out there....,
  Its the question that drives us...."


-----Original Message-----
From: Jan Hubicka [mailto:hubicka@ucw.cz]
Sent: Thursday, February 12, 2004 5:06 PM
To: Konark Goel, Noida
Cc: Jan Hubicka; gcc@gcc.gnu.org
Subject: Re: gcc loop unrolling problem ??


> 
> Actually -O3 generated code looks better than the code generated by -O3
and
> - funroll-all-loops condition combined. it is better optimized, so i think

The -O3 -funroll-all-loops code has unrolled loop, while -O3 has normal
loop.  You get what you are asking for :)
The unrolled loop will probably run marginally faster as you execute
less jmp instructions and most of CPU cores can not get past more than
one jump per cycle.  But it likely won't make much difference especially
because your function is infinite (and probably buggy) :)

> it both the conditions should generate the code generated by -O3 as it is
> more optimized.
> Also why is the loop being unrolled only 8 times ? even after changing
> switch values it unrolls to 8 times only...? is there something special
> about this no. 8 ?

The number of unrollings depends on size of the loop and is bound to 8
maximally.  Your loop has only single instruction so you get maximal
unrolling.  See documentation of --param max-unrolled-insns,
max-uroll-times and friends.

Honza
>  
> thanks,
> Kon ??
> "The answer is out there....,
>   Its the question that drives us...."
> 
> 
> -----Original Message-----
> From: Jan Hubicka [mailto:hubicka@ucw.cz]
> Sent: Thursday, February 12, 2004 4:14 PM
> To: Konark Goel, Noida
> Cc: gcc@gcc.gnu.org
> Subject: Re: gcc loop unrolling problem ??
> 
> 
> > 
> > I compiled a gcc testcase with only -O3 option and also with -O3 and
> > -funroll-all-loops options combined.... For the first case (-O3 option)
it
> > is generating quite a correct assembly...but in case of
-funroll-all-loops
> > it is generating quite a no. of calls, which actually is not needed. I
> guess
> > there's some problem in it. Also the no. of calls being generated is
> > dependent upon the minimum and maximum values in the switch cases !! 
> > 
> > the testcase is this : 
> > 
> > /* TestCase starts here */
> > extern int getch();
> > extern int class();
> > 
> > int
> > token()
> > {
> >     int state = 1;
> > 
> >     while (1) {
> > 	int c=0;
> > 	c = getch();
> > 	switch (state) {
> > 	case 1: break;
> > 	case 4: break;
> > 	case 5: break;
> > 	case 6: 
> >             {
> > 	        switch (class(c)) {
> > 	        default: break;
> > 	        }
> > 	    } break;
> > 	case 7:	break;
> > 	}
> >     }
> > }
> > /* TestCase ends.....*/
> > 
> > 
> > ;Assembly for -O3 -funroll-all-loops case ....
> > 
> > 	.file	"990801-1.c"
> > 	.text
> > 	.p2align 2,,3
> > .globl token
> > 	.type	token,@function
> > token:
> > 	pushl	%ebp
> > 	movl	%esp, %ebp
> > 	subl	$8, %esp
> > 	.p2align 2,,3
> > .L16:
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	call	getch
> > 	jmp	.L16
> > .Lfe1:
> > 	.size	token,.Lfe1-token
> > 	.ident	"GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
> > 
> > 
> > ;assembly for only -O3 condition...
> > 
> > .file	"990801-1.c"
> > 	.text
> > 	.p2align 2,,3
> > .globl token
> > 	.type	token,@function
> > token:
> > 	pushl	%ebp
> > 	movl	%esp, %ebp
> > 	subl	$8, %esp
> > 	.p2align 2,,3
> > .L16:
> > 	call	getch
> > 	jmp	.L16
> > .Lfe1:
> > 	.size	token,.Lfe1-token
> > 	.ident	"GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
> > 
> > ;assembly ends..
> > 
> > 
> > as is clear it creates a strange assembly with -O3 -funroll-all-loops
> > option......Is this a BUG ??
> 
> I think it is just result of unrolling+constant propagation of "state",
> so it looks like valid transformation to me.  Why do you think it is
> strange?
> 
> Honza
> > 
> > hoping to get a quick response..
> > 
> > thanks,
> > Kon ??
> > "The answer is out there....,
> >   Its the question that drives us...."


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]