This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
- From: Richard Henderson <rth at redhat dot com>
- To: "Araneda, Dorian" <dorian dot araneda at intel dot com>
- Cc: "'rth at gcc dot gnu dot org'" <rth at gcc dot gnu dot org>, "'gcc-bugs at gcc dot gnu dot org'" <gcc-bugs at gcc dot gnu dot org>, "'gcc-prs at gcc dot gnu dot org'" <gcc-prs at gcc dot gnu dot org>, "'nobody at gcc dot gnu dot org'" <nobody at gcc dot gnu dot org>, "'gcc-gnats at gcc dot gnu dot org'" <gcc-gnats at gcc dot gnu dot org>
- Date: Tue, 2 Apr 2002 10:17:41 -0800
- Subject: Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
- References: <A5974D8E5F98D511BB910002A50A66470196C7AF@hdsmsx103.hd.intel.com>
On Tue, Apr 02, 2002 at 09:59:45AM -0800, Araneda, Dorian wrote:
> I dont think you understand what i am talking about.
I'm pretty sure I do.
> The assembly output shows that memcopy is being used
> when optimizations are turned on even a the minimum level.
Yes.
> The code above is a legitamate call which does not
> need memcopy in place of optimized assembly code.
"Need"? Well, sure. We could also expand printf inline
every time we saw it, but we don't. What we want is to
generate efficient code, and that often involves this
curious invention called "subroutines", particularly for
larger, more complicated hunks of code.
> This is not intuitive to the normal programmer.
So?
> I have no problem with memcopy being an exported kernel symbol.
> Memcopy may be superduper wonderfuly optimized but I do not want
> it or any other open source symbols in our closed source library.
"memcpy" is hardly an "open source symbol". It's an ISO C
sanctioned library entry point.
I have no sympathy.
r~