[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiw6q1hk7QHP+8M6H9zRDj-yJ8p-KyhQS9gTJA8NopYkA@mail.gmail.com>
Date: Mon, 16 Sep 2019 16:26:20 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Rasmus Villemoes <linux@...musvillemoes.dk>,
Borislav Petkov <bp@...en8.de>,
Rasmus Villemoes <mail@...musvillemoes.dk>,
x86-ml <x86@...nel.org>, Josh Poimboeuf <jpoimboe@...hat.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Improve memset
On Mon, Sep 16, 2019 at 4:14 PM Andy Lutomirski <luto@...nel.org> wrote:
>
> Well, when I wrote this email, I *thought* it was inlining the
> 'memset' function, but maybe I just can't read gcc's output today.
Not having your compiler, it's also possible that it works for you,
but just doesn't work for me.
> It seems like gcc is maybe smart enough to occasionally optimize
> memset just because it's called 'memset'. This generates good code:
Yup, that does the rigth thing for me and ignores the definition of
memset() in favor of the built-in one.
However, at least part of this discussion started because of the
reverse problem (turning a couple of assignments into memset), and the
suggestion that we might be able to use -ffreestanding together with
#define memset __builtin_memset
and then your nice code generation goes away, because the magical
treatment of memset goes away. I get
one_word:
xorl %eax, %eax
ret
not_one_word:
movq %rsi, %rdx
xorl %esi, %esi
jmp memset
despite having that "inline void *memset()" definition.
Linus
Powered by blists - more mailing lists