global variable store optimization

[Aaron Holtzman <aholtzma@ess4.engr.UVic.CA>]

Hi there,

While looking at the assembly output of my noise generator, I noticed
something odd about the way gcc treats global variables. It appears
that even with -O3, gcc likes to store the result of a global variable
calculation. The problem disappears when I explicitly copy the global
into a local upon entry and store it upon return. I've seen this 
behavior on both sparc and x86. Sun's compiler doesn't seem to
do this. Is copying the global into the local the only way around
this? Thanks!

Code follows.

cheers,
aaron



------------------------------------------------------------------
uint_32 state = 1;

uint_16
my_rand()
{
	int i;

	for(i=0;i<10;i++)
	{
		state <<= 1;	

		if(state & 0x8000)
			state ^= 0x4001;
	}

	return ((state >> 15) & 0x3ff);
}
												
---------------------------------------------------------------------
egcs-2.91.66 -O3 -g 

00010600 <my_rand>:

uint_16
my_rand()
{
	int i;

	for(i=0;i<10;i++)
10600:       13 00 00 81     sethi  %hi(0x20400), %o1
10604:       05 00 00 10     sethi  %hi(0x4000), %g2
10608:       96 10 a0 01     or  %g2, 1, %o3 ! 4001 <*ABS*+0x4001>
1060c:       90 10 00 09     mov  %o1, %o0
10610:       86 10 20 00     clr  %g3
10614:       15 00 00 20     sethi  %hi(0x8000), %o2
	{
		state <<= 1;    
10618:       c4 02 22 ec     ld  [ %o0 + 0x2ec ], %g2
1061c:       85 28 a0 01     sll  %g2, 1, %g2

		if(state & 0x8000)
10620:       80 88 80 0a     btst  %g2, %o2
10624:       02 80 00 04     be  10634 <my_rand+0x34>
10628:       c4 22 22 ec     st  %g2, [ %o0 + 0x2ec ]   <= evil stores
			state ^= 0x4001;
1062c:       84 18 80 0b     xor  %g2, %o3, %g2
10630:       c4 22 62 ec     st  %g2, [ %o1 + 0x2ec ]   <= evil stores
10634:       86 00 e0 01     inc  %g3
10638:       80 a0 e0 09     cmp  %g3, 9
1063c:       04 bf ff f8     ble  1061c <my_rand+0x1c>
10640:       c4 02 22 ec     ld  [ %o0 + 0x2ec ], %g2
	}

	return ((state >> 15) & 0x3ff);
10644:       d0 02 62 ec     ld  [ %o1 + 0x2ec ], %o0
10648:       91 32 20 0f     srl  %o0, 0xf, %o0
}
------------------------------------------------------------------
For reference, here's the output from Suns SPARCworks C v4.2 with -fast

00010800 <my_rand>:
10800:  sethi  %hi(0x20800), %g1
10804:  sethi  %hi(0x4000), %g2
10808:  ld  [ %g1 + 0x260 ], %g1
1080c:  clr  %o5
10810:  add  %g2, 1, %g4
10814:  sethi  %hi(0x8000), %g3
10818:  sll  %g1, 1, %g2
1081c:  btst  %g2, %g3
10820:  mov  %g2, %g1
10824:  inc  %o5
10828:  be  10834 <my_rand+0x34>
1082c:  cmp  %o5, 0xa
10830:  xor  %g2, %g4, %g1
10834:  bl  1081c <my_rand+0x1c>
10838:  sll  %g1, 1, %g2
1083c:  srl  %g1, 0xf, %g2
10840:  sethi  %hi(0x20800), %g3
10844:  and  %g2, 0x3ff, %g2
10848:  st  %g1, [ %g3 + 0x260 ]
1084c:  sll  %g2, 0x10, %o0
10850:  retl 
10854:  srl  %o0, 0x10, %o0