From: Stephen Hemminger <[email protected]>
Date: Fri, 17 Aug 2007 20:31:39 -0700
> On Fri, 17 Aug 2007 18:57:00 -0700
> Arjan van de Ven <[email protected]> wrote:
>
> >
> > On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> > > On Fri, 17 Aug 2007 18:49:34 -0700
> > > Arjan van de Ven <[email protected]> wrote:
> > >
> > > >
> > > > On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > > > > Tne network code does memset for 6 and 8 byte values, that can easily
> > > > > be optimized into simple assignments without string instructions.
> > > >
> > > >
> > > > so... question.
> > > > Why are we doing this by hand? Wouldn't gcc just generate this code in
> > > > the first place (when using __builtin_memset)? I very much suspect it
> > > > would (and if some version doesn't.... we really ought to get that
> > > > fixed)
> > >
> > > i386 and x86_64 are not using __builtin_memset, as least from the
> > > code that I see generated.
> >
> > .. maybe we should just fix it that way then?
> >
> There probably is history behind the decision, like gcc problems
> on some old compiler version.
Yes, but those reasons are very likely no longer true.
In fact, just removing the memcpy macro altogether is the best
thing to do. GCC will do inline memcpy when appropriate.
Then put all of the rep; movsl; etc. code in an external
assembler file and name the routine memcpy.
The inlining is senseless even if it all gets optimized away
into the bare necessary instructions. All the x86 registers
get clobbered in most of those rep; movsl; code paths, so
it's hardly going to be more expensive to extern the thing
and it will make the kernel smaller to boot.
Anyways the point is to make the real C symbol called by "memcpy"
because that's what makes all the automatic gcc inline memcpy logic
kick in. If you define the "memcpy" as a macro which calls
differently named functions, you bypass all of that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
