public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: osv@javad.ru
To: gcc-gnats@gcc.gnu.org
Subject: optimization/9567: Using struct fields produces worse code than stand-alone vars.
Date: Tue, 04 Feb 2003 12:16:00 -0000	[thread overview]
Message-ID: <20030204120749.18038.qmail@sources.redhat.com> (raw)


>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:


                 reply	other threads:[~2003-02-04 12:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030204120749.18038.qmail@sources.redhat.com \
    --to=osv@javad.ru \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).