This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Undefined references to 'memcpy' when compiling Linux Kernel
- To: ak at suse dot de, john at Calva dot COM
- Subject: RE: Undefined references to 'memcpy' when compiling Linux Kernel
- From: Mike Stump <mrs at windriver dot com>
- Date: Mon, 19 Jun 2000 16:19:16 -0700 (PDT)
- Cc: gandalf at winds dot org, gcc at gcc dot gnu dot org, hjl at lucon dot org, jgarzik at mandrakesoft dot com, linux-kernel at vger dot rutgers dot edu, nalan at lxorguk dot ukuu dot org dot uk
> 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. :-)