public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: osv@javad.ru
To: gcc-gnats@gcc.gnu.org
Subject: optimization/9566: Inline function produces much worse code than manual inlining.
Date: Tue, 04 Feb 2003 10:26:00 -0000	[thread overview]
Message-ID: <20030204101610.18874.qmail@sources.redhat.com> (raw)


>Number:         9566
>Category:       optimization
>Synopsis:       Inline function produces much worse code than manual inlining.
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 04 10:26:00 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 g1() calls inline function copy() 
and g2() is equivalent to g1() but the body of copy() is inserted
into the body of g2() manually. The assembly code produced for
g1() is very bad compared to those of g2(). The difference is most visible
for RISC processors (an example PowerPC assembly result is shown) 
though it could be seen on CISC processors as well.

The 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 copy() { *++dest = *++src; }
};

void g1() {
  A a;
  for(int i = 0; i < 10; ++i)
    a.copy();
}

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

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

$ ~/try-3.2/tools/bin/ppc-rtems-gcc -c -O4 -save-temps -mregnames struct.cc -o struct.o
$ cat struct.s

	.file	"struct.cc"
	.section	".text"
	.align 2
	.globl _Z2g1v
	.type	_Z2g1v, @function
_Z2g1v:
.LFB5:
	li %r3,10
	mtctr %r3
	stwu %r1,-16(%r1)
.LCFI0:
	addi %r8,%r1,8
.L10:
	lwz %r5,8(%r1)
	lwz %r3,4(%r8)
	addi %r6,%r5,1
	addi %r7,%r3,1
	stw %r7,4(%r8)
	stw %r6,8(%r1)
	lbz %r4,1(%r5)
	stb %r4,1(%r3)
	bdnz .L10
	addi %r1,%r1,16
	blr
.LFE5:
	.size	_Z2g1v, .-_Z2g1v
	.align 2
	.globl _Z2g2v
	.type	_Z2g2v, @function
_Z2g2v:
.LFB6:
	li %r3,10
	mtctr %r3
	li %r7,0
	li %r8,0
.L19:
	addi %r7,%r7,1
	lbz %r4,0(%r7)
	addi %r8,%r8,1
	stb %r4,0(%r8)
	bdnz .L19
	blr
.LFE6:
	.size	_Z2g2v, .-_Z2g2v
	.ident	"GCC: (GNU) 3.3 20030203 (prerelease)"

>How-To-Repeat:
Compile provided C++ code with '-O4 -save-temps' and look at resulting assembly.
>Fix:

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


             reply	other threads:[~2003-02-04 10:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-04 10:26 osv [this message]
2003-04-14 23:46 Andrew Pinski
2003-04-15  0:16 Andrew Pinski

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=20030204101610.18874.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).