Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.

[Richard Henderson <rth at redhat dot com>]

The following reply was made to PR optimization/3329; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: "Araneda, Dorian" <dorian.araneda@intel.com>
Cc: "'rth@gcc.gnu.org'" <rth@gcc.gnu.org>,
   "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
   "'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
   "'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
   "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Subject: Re: optimization/3329: optimization large memory copies uses kern el memcpy function without user's knowledge.
Date: Tue, 2 Apr 2002 10:17:41 -0800

 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~