optimization/9567: Using struct fields produces worse code than stand-alone vars.

osv@javad.ru osv@javad.ru
Tue Feb 4 12:16:00 GMT 2003


>Number:         9567
>Category:       optimization
>Synopsis:       Using struct fields produces worse code than stand-alone vars.
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 04 12:16:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Sergei Organov
>Release:        gcc version 3.3 20030203 (prerelease)
>Organization:
>Environment:
Linux 2.4.20 i686
>Description:
In the code below functions f1() and f2() are equivalent, but
assembly code produced for f1() is worse than those for f2().
The assembly below demonstrates the result for PowerPC, however
similar result could be seen for ix86.

The C/C++ code (note that the code is minimized to demonstrate the problem,
so please ignore using of unitialized variables):

struct A {
  char const* src;
  char* dest;
};

void f1() {
  A a;
  for(int i = 0; i < 10; ++i)
    *++a.dest = *++a.src;
}

void f2() {
  char const* src;
  char* dest;
  for(int i = 0; i < 10; ++i)
    *++dest = *++src;
}

The resulting assembly for PowerPC (note the loop body is
4 vs 2 instructions):

$ ~/try-3.2/tools/bin/ppc-rtems-gcc -c -O4 -save-temps -mregnames struct1.cc -o struct1.o
$ cat struct1.s
	.file	"struct1.cc"
	.section	".text"
	.align 2
	.globl _Z2f1v
	.type	_Z2f1v, @function
_Z2f1v:
.LFB4:
	li %r3,10
	mtctr %r3
	li %r7,0
	li %r8,0
.L9:
	addi %r7,%r7,1
	lbz %r4,0(%r7)
	addi %r8,%r8,1
	stb %r4,0(%r8)
	bdnz .L9
	blr
.LFE4:
	.size	_Z2f1v, .-_Z2f1v
	.align 2
	.globl _Z2f2v
	.type	_Z2f2v, @function
_Z2f2v:
.LFB5:
	li %r3,10
	mtctr %r3
.L18:
	lbzu %r3,1(%r9)
	stbu %r3,1(%r11)
	bdnz .L18
	blr
.LFE5:
	.size	_Z2f2v, .-_Z2f2v
	.ident	"GCC: (GNU) 3.3 20030203 (prerelease)"
>How-To-Repeat:
Compile provided C/C++ code with '-O4 -save-temps' and look at
resulting assembly.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the Gcc-bugs mailing list