> From: "John Hughes" <john@Calva.COM>
> To: <ak@suse.de>
> Cc: "H . J . Lu" <hjl@lucon.org>, "Jeff Garzik" <jgarzik@mandrakesoft.com>,
> "Byron Stanoszek" <gandalf@winds.org>, <linux-kernel@vger.rutgers.edu>,
> <alan@lxorguk.ukuu.org.uk>, <gcc@gcc.gnu.org>
> Date: Mon, 19 Jun 2000 12:04:52 +0200
> > Inlined memcpy can be very big in some cases, e.g. when gcc cannot
> > figure out the alignment of the target and destination pointers
> But in the case reported on a '386 I'd expect the inlined code to
> be tiny, smaller than the call.
Let me put this plainly, since no one else has. Because there is a
benchmark that says is it more optimal? Smaller is merely one
dimension in optimality, faster is yet another.
If you want to question why it is better, it would be more helpful if
you just provided a testcase, and the generated code, and an example
of how you would have liked the compiler to generate the code, with
performance numbers to back your claim. If you can't find a case
where it is worse, maybe it's not. If you can, maybe we can then
explain why dirtying the cache is bad, or some other obscure second
order effect. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:18 EST