From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement prefetch (V2)
Date: Wed, 17 Nov 2010 09:49:39 +0000 [thread overview]
Message-ID: <20101117094938.GA12227@linux-sh.org> (raw)
In-Reply-To: <1289976617-27704-1-git-send-email-peppe.cavallaro@st.com>
On Wed, Nov 17, 2010 at 10:27:19AM +0100, Giuseppe CAVALLARO wrote:
> GCC's __builtin_prefetch() was introduced a long time ago, all
> supported GCC versions have it.
> So this patch removes the ARCH_HAS_PREFETCH and ARCH_HAS_PREFETCHW
> macros, defined for SH2A and SH4 that will fall back on
> __builtin_prefetch() through the generic code:
> include/linux/prefetch.h
>
> The builtin usage should be more efficient that an __asm__
> because less barriers, and because the compiler doesn't see the
> inst as a "black box" allowing better code generation.
> Many thanks to Christian Bruel <christain.bruel@st.com> for his
> support on evaluate the impact of the gcc built-in on SH4 arch.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
Actually now that I think about it, it's not that simple. If
ARCH_HAS_PREFETCH goes away then we lose prefetch_range() (which
admittely isn't called anywhere that matters, but it may in the future).
If gcc is smart enough to optimize out __builtin_prefetch() for the cases
where nothing has to be done, then the ARCH_HAS_PREFETCH define could
simply be killed and each arch would be responsible for establishing the
prefetch stride (this seems to vary between the size of an L1 or L2
cacheline depending on the platform). This is a different change though,
and is something you would have to bring up on linux-arch and
linux-kernel as a separate patch.
Perhaps the easiest solution for now is just to stick with your first
version, which at least retains the stride data and prefetch_range()
behaviour. If you wish to sort out the PREFETCH_STRIDE/ARCH_HAS_PREFETCH
and prefetch_range() mess separately then of course that's something we
can deal with incrementally, too.
next prev parent reply other threads:[~2010-11-17 9:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 6:50 [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement prefetch() Giuseppe CAVALLARO
2010-11-17 8:17 ` Paul Mundt
2010-11-17 8:51 ` [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement Peppe CAVALLARO
2010-11-17 9:27 ` [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement prefetch (V2) Giuseppe CAVALLARO
2010-11-17 9:49 ` Paul Mundt [this message]
2010-11-17 11:01 ` [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement Peppe CAVALLARO
2010-11-18 6:09 ` [PATCH (sh-2.6)] sh: Use GCC __builtin_prefetch() to implement prefetch (V2) Paul Mundt
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=20101117094938.GA12227@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.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