From: Jeff Garzik <jgarzik@pobox.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@transmeta.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [BK+PATCH] remove __constant_memcpy
Date: Thu, 17 Apr 2003 10:32:02 -0400 [thread overview]
Message-ID: <20030417143202.GA18749@gtf.org> (raw)
In-Reply-To: <1050585430.31390.32.camel@dhcp22.swansea.linux.org.uk>
On Thu, Apr 17, 2003 at 02:17:16PM +0100, Alan Cox wrote:
> On Iau, 2003-04-17 at 01:57, Jeff Garzik wrote:
> > The patch below is the conservative, obvious patch. It only kicks in
> > when __builtin_constant_p() is true, and it only applies to the i386
> > arch.
>
> You are assuming the compiler is smart about stuff - it doesnt know
> SSE/MMX for page copies etc. For small copies it should alays win, but
Prior to my patch, __constant_memcpy was -already- only used for small,
constant-size copies.
Therefore, my patch applied __builtin_memcpy only to small,
constant-size copies. The existing kernel custom-memcpy code continued
to perform as expected.
You and Linus both seem to think MMX/SSE/SSE2 is somehow in the
equation, but I do not see that at all. I left those paths alone.
Clarification/LART requested...
> isn't it best if so to use __builtin_memcpy without our existing
> macros not just trust the compiler ?
hum, I didn't parse this at all:
Use of __builtin_memcpy implies trusting the compiler :)
Maybe you meant s/without/with/ ?
Jeff
next prev parent reply other threads:[~2003-04-17 14:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-17 0:57 [BK+PATCH] remove __constant_memcpy Jeff Garzik
2003-04-17 1:04 ` Jeff Garzik
2003-04-17 2:06 ` Linus Torvalds
2003-04-17 8:46 ` Arjan van de Ven
2003-04-17 9:02 ` Roman Zippel
2003-04-17 9:04 ` Arjan van de Ven
2003-04-17 9:11 ` Jakub Jelinek
2003-04-17 16:07 ` Linus Torvalds
2003-04-17 19:07 ` Jeff Garzik
2003-04-17 19:19 ` Jeff Garzik
2003-04-17 19:54 ` Linus Torvalds
2003-04-17 23:49 ` Jeff Garzik
2003-04-17 23:52 ` Jeff Garzik
2003-04-17 23:59 ` Linus Torvalds
2003-04-18 0:29 ` H. Peter Anvin
2003-04-18 9:06 ` Arjan van de Ven
2003-04-18 14:31 ` Timothy Miller
2003-04-18 15:07 ` Richard B. Johnson
2003-04-17 22:58 ` J.A. Magallon
2003-04-17 23:10 ` Jeff Garzik
2003-04-17 13:17 ` Alan Cox
2003-04-17 13:17 ` Alan Cox
2003-04-17 14:32 ` Jeff Garzik [this message]
2003-04-17 14:40 ` Jeff Garzik
2003-04-17 20:01 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2003-04-17 2:22 Nakajima, Jun
2003-04-17 23:50 Chuck Ebbert
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=20030417143202.GA18749@gtf.org \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.