lkml.org 
[lkml]   [2003]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [BK+PATCH] remove __constant_memcpy
Date
From
I think the fear is valid. Intel compiler, for example, uses FP if it's required to optimize the code with a particular option. And the option is not necessary obvious when telling if it uses FP or not (and it does not matter for most users). This could happen with gcc.

I think we can do it better than the compiler does, because we know the usage better, e.g. alignment, typical size, etc.

Thanks,
Jun

> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> Sent: Wednesday, April 16, 2003 7:06 PM
> To: Jeff Garzik
> Cc: LKML
> Subject: Re: [BK+PATCH] remove __constant_memcpy
>
>
> On Wed, 16 Apr 2003, Jeff Garzik wrote:
> >
> > gcc's __builtin_memcpy performs the same function (and more) as the
> > kernel's __constant_memcpy. So, let's remove __constant_memcpy, and let
> > the compiler do it.
>
> Please don't.
>
> There's no way gcc will EVER get the SSE2 cases right. It just cannot do
> it. In fact, I live in fear that we will have to turn off the compiler
> intrisics entirely some day just because there is always the worry that
> gcc will start using FP.
>
> So the advantage of doing our own memcpy() is not that it's necessarily
> faster than the gcc built-in, but simply because I do not believe that the
> gcc people care enough about the kernel to let them make the choice.
>
> Linus
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.043 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site