On Monday 20 August 2007 19:56, Jan Hubicka wrote:
> > > > The problem is with the optimization flags: passing -Os causes the
> > > > compiler to be stupid and not inline any memset/memcpy functions.
> > >
> > > you get what you ask for.. if you don't want that then don't ask for
> > > it ;)
>
> > > The problem is with the optimization flags: passing -Os causes the
> compiler
> > > to be stupid and not inline any memset/memcpy functions.
> >
> > you get what you ask for.. if you don't want that then don't ask for
> > it ;)
>
> Well, the compiler is really being dumb about -Os and
> so the code gets bigger and worse in every way.
I guess it would make sense to file this as a bug in the gcc
bugzilla
Another useful enhancement might be to have a -finline-string-functions
or similar that could be set with -Os. In general I've been wondering
for some time if the kernel really
> > The problem is with the optimization flags: passing -Os causes the compiler
> > to be stupid and not inline any memset/memcpy functions.
>
> you get what you ask for.. if you don't want that then don't ask for
> it ;)
Well, the compiler is really being dumb about -Os and in fact it's
giv
On Mon, 2007-08-20 at 08:52 -0700, Stephen Hemminger wrote:
> The problem is with the optimization flags: passing -Os causes the compiler
> to be stupid and not inline any memset/memcpy functions.
you get what you ask for.. if you don't want that then don't ask for
it ;)
-
To unsubscribe from
On Sun, 19 Aug 2007 20:24:24 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > I am looking at current source, built with current (non-experimental) GCC
> > from Fedora Core 7. If I dissassemble ether_setup, which is
> >
> > void ether_setup(struct net_device *dev)
> > {
> > ...
> >
> > mem
> I am looking at current source, built with current (non-experimental) GCC
> from Fedora Core 7. If I dissassemble ether_setup, which is
>
> void ether_setup(struct net_device *dev)
> {
> ...
>
> memset(dev->broadcast, 0xFF, ETH_ALEN);
> }
>
> I see a tail recursion (jmp) to memset which
On Sat, 18 Aug 2007 20:55:11 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > The problem is that on x86-64 you are overriding memset()
>
> I don't. You must be looking at old source
>
> asm-x86_64/string.h 2.6.23rc3:
>
> #define __HAVE_ARCH_MEMSET
> void *memset(void *s, int c, size_t n);
> The problem is that on x86-64 you are overriding memset()
I don't. You must be looking at old source
asm-x86_64/string.h 2.6.23rc3:
#define __HAVE_ARCH_MEMSET
void *memset(void *s, int c, size_t n);
I wanted to do the same on i386 too, but there were some minor obstacles.
The problem is th
On Sat, 18 Aug 2007 11:46:24 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Saturday 18 August 2007 01:34:46 Stephen Hemminger wrote:
> > Optimize uses of memset with small constant offsets.
> > This will generate smaller code, and avoid the slow rep/string instructions.
> > Code copied from i38
On Saturday 18 August 2007 01:34:46 Stephen Hemminger wrote:
> Optimize uses of memset with small constant offsets.
> This will generate smaller code, and avoid the slow rep/string instructions.
> Code copied from i386 with a little cleanup.
Newer gcc should do all this on its own. That is why I
Stephen Hemminger a écrit :
Optimize uses of memset with small constant offsets.
This will generate smaller code, and avoid the slow rep/string instructions.
Code copied from i386 with a little cleanup.
You obviously didnt test it, did you ?
How can you be sure this is going to speedup things
Optimize uses of memset with small constant offsets.
This will generate smaller code, and avoid the slow rep/string instructions.
Code copied from i386 with a little cleanup.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/string.h 2007-08-17 15:14:32.0
13 matches
Mail list logo
