From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Albrecht Dreß" <albrecht.dress@arcor.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
Date: Wed, 03 Jun 2009 08:51:25 +1000 [thread overview]
Message-ID: <1243983086.27194.7.camel@pasglop> (raw)
In-Reply-To: <1243968361.4951.0@antares>
On Tue, 2009-06-02 at 20:45 +0200, Albrecht Dreß wrote:
>
> which drops the r1 accesses, but still produces the sub-optimal loop.
> Is this a gcc regression, or did I miss something here? Probably the
> only bullet-proof way is to write some core loops in assembly... :-/
Well, gcc may be right here. What you call the "optimal" loop uses the
lwzu instruction. An interesting thing about this instruction is that
it updates two GPRs at completion (I'm ignoring the load multiple and
string instructions on purpose here).
Now, quite a few simple implementations don't have two write ports to
the GPR file, nor the logic to handle hazards properly with two GPRs
being updated... which means the instruction is very likely to take a
very inefficient path through the pipeline. On server processors, I'm
pretty sure it's just cracked into a load and an add anyway.
I wouldn't be surprised thus if the loop variant with the separate add
ends up more efficient on most implementations around.
Of course, the loop above could use some unrolling to put some distance
between the load and the store of the loaded value.
Cheers,
Ben.
next prev parent reply other threads:[~2009-06-02 22:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 20:00 [PATCH] powerpc: tiny memcpy_(to|from)io optimisation Albrecht Dreß
2009-05-28 16:13 ` Joakim Tjernlund
2009-05-28 19:50 ` Albrecht Dreß
2009-05-29 6:31 ` Joakim Tjernlund
2009-05-31 10:11 ` Albrecht Dreß
2009-06-01 6:14 ` Joakim Tjernlund
2009-06-02 18:45 ` Albrecht Dreß
2009-06-02 22:51 ` Benjamin Herrenschmidt [this message]
2009-06-03 14:36 ` Kenneth Johansson
2009-06-03 18:35 ` Albrecht Dreß
2009-06-11 17:07 ` Wolfram Sang
2009-06-11 17:30 ` Grant Likely
2009-06-19 18:42 ` Lorenz Kolb
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=1243983086.27194.7.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=albrecht.dress@arcor.de \
--cc=linuxppc-dev@ozlabs.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 NNTP newsgroup(s).