From: Oleg Smolsky <oleg.smolsky@riverbed.com>
To: Xinliang David Li <davidxl@google.com>
Cc: Andrew Pinski <pinskia@gmail.com>, gcc@gcc.gnu.org
Subject: Re: Performance degradation on g++ 4.6
Date: Wed, 24 Aug 2011 19:51:00 -0000 [thread overview]
Message-ID: <4E555623.1040408@riverbed.com> (raw)
In-Reply-To: <CAAkRFZ+GdFaWd+3CeoNyEPy=o_Yj3yuusSOsFhmwcHNVrZ5tPw@mail.gmail.com>
On 2011/8/23 11:38, Xinliang David Li wrote:
> Partial register stall happens when there is a 32bit register read
> followed by a partial register write. In your case, the stall probably
> happens in the next iteration when 'add eax, 0Ah' executes, so your
> manual patch does not work. Try change
>
> add al, [dx] into two instructions (assuming esi is available here)
>
> movzx esi, ds:data8[dx]
> add eax, esi
>
I patched the code to use "movzx edi" but the result is a little clumsy
as the loop is based on the virtual address rather than index. Also, the
sequence is a bit bigger so I had to spill the patch into the preceding
padding:
.text:0000000000400D80 loc_400D80:
.text:0000000000400D80 mov edx, offset data8
.text:0000000000400D85 xor eax, eax
.text:0000000000400D87 nop
.text:0000000000400D88 nop
.text:0000000000400D89 nop
.text:0000000000400D8A nop
.text:0000000000400D8B nop
.text:0000000000400D8C
.text:0000000000400D8C loc_400D8C:
.text:0000000000400D8C movzx edi, byte ptr [rdx+0]
.text:0000000000400D90 add eax, edi
.text:0000000000400D92 add eax, 0Ah
.text:0000000000400D95 add rdx, 1
.text:0000000000400D99 cmp rdx, 503480h
.text:0000000000400DA0 jnz short loc_400D8C
.text:0000000000400DA2 movsx eax, al
.text:0000000000400DA5 add ecx, 1
.text:0000000000400DA8 add ebx, eax
.text:0000000000400DAA cmp ecx, esi
.text:0000000000400DAC jnz short loc_400D80
The performance improved from 2.84 sec (563.38 M ops/s) to 1.51 sec
(1059.60 M ops/s). It's close to the code emitted by g++4.1 now. Very funky!
So, this is one test out of the suite. Many of them degraded... Are you
guys interested in looking at other ones? Or is there something to be
fixed in the register allocation logic?
Oleg.
next prev parent reply other threads:[~2011-08-24 19:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-29 18:08 Oleg Smolsky
2011-07-29 18:14 ` Xinliang David Li
2011-07-29 21:08 ` Oleg Smolsky
2011-07-29 21:29 ` Xinliang David Li
2011-08-01 18:44 ` Oleg Smolsky
2011-08-02 5:48 ` Xinliang David Li
2011-08-23 1:09 ` Oleg Smolsky
2011-08-23 1:34 ` Oleg Smolsky
2011-08-23 1:37 ` Andrew Pinski
2011-08-23 17:47 ` Oleg Smolsky
2011-08-23 18:38 ` Xinliang David Li
2011-08-24 19:51 ` Oleg Smolsky [this message]
2011-08-24 20:03 ` Xinliang David Li
2011-08-24 21:26 ` Oleg Smolsky
2011-08-24 21:57 ` Xinliang David Li
2011-08-24 22:14 ` Oleg Smolsky
2011-08-02 9:27 ` Richard Guenther
2011-08-03 19:12 ` Xinliang David Li
2011-07-30 9:24 ` Richard Guenther
2011-07-30 14:57 Benjamin Redelings I
2011-08-01 18:04 ` Oleg Smolsky
2011-08-01 18:14 ` Marc Glisse
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=4E555623.1040408@riverbed.com \
--to=oleg.smolsky@riverbed.com \
--cc=davidxl@google.com \
--cc=gcc@gcc.gnu.org \
--cc=pinskia@gmail.com \
/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).