[Bug optimization/12814] New: Missed optimization with non-static but non-changing local arrays

["bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12814

           Summary: Missed optimization with non-static but non-changing
                    local arrays
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bangerth at dealii dot org
                CC: gcc-bugs at gcc dot gnu dot org

For this small code snippet:
-------------------
int f1 (const int i) 
{
  const int x[3] = { 13, 26, 39 };
  return x[i];
}

int f2 (const int i) 
{
  static const int x[3] = { 13, 26, 39 };
  return x[i];
}
-------------------
here is essentially what we get on x86 with -O3 and
-fomit-frame-pointer with all present branches:
-------------------
_Z2f1i:
	subl	$28, %esp
	movl	$26, %ecx
	movl	32(%esp), %eax
	movl	$13, (%esp)
	movl	$39, %edx
	movl	%ecx, 4(%esp)
	movl	%edx, 8(%esp)
	movl	(%esp,%eax,4), %eax
	addl	$28, %esp
	ret

_ZZ2f2iE1x:
	.long	13
	.long	26
	.long	39
_Z2f2i:
	movl	4(%esp), %eax
	movl	_ZZ2f2iE1x(,%eax,4), %eax
	ret
------------------
Obviously, the code for f2 is more efficient than that for f1.
Things get even worse if the array gets larger, since then its
contents are spilled onto the stack in f1. 

The point is that this is really not necessary: gcc certainly has all
the abilities to detect that the array in f1 is unchanging and that it
could be treated as static even though it is not declared as
that. Note also that the code generated for f2 _never_ uses more
memory than that in f1, since the code for writing a constant into a
register or a stack slot uses _more_ memory than having the constant
in a table.

W.