mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Denis Vlasenko <vda@ilport.com.ua>
Cc: Gerold Jury <gerold.ml@inode.at>,
	jakub@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	gcc@gcc.gnu.org
Subject: Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
Date: Fri, 1 Apr 2005 23:43:22 +0200	[thread overview]
Message-ID: <20050401214322.GA7175@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <200503300916.00781.vda@ilport.com.ua>

> On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
> > 
> > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> > >> > /*
> > >> >  * This looks horribly ugly, but the compiler can optimize it totally,
> > >> >  * as the count is constant.
> > >> >  */
> > >> > static inline void * __constant_memcpy(void * to, const void * from,
> > >> > size_t n) {
> > >> >         if (n <= 128)
> > >> >                 return __builtin_memcpy(to, from, n);
> > >>
> > >> The problem is that in GCC < 4.0 there is no constant propagation
> > >> pass before expanding builtin functions, so the __builtin_memcpy
> > >> call above sees a variable rather than a constant.
> > >
> > >or change "size_t n" to "const size_t n" will also fix the issue.
> > >As we do some (well very little and with inlining and const values)
> > >const progation before 4.0.0 on the trees before expanding the builtin.
> > >
> > >-- Pinski
> > >-
> > I used the following "const size_t n" change on x86_64
> > and it reduced the memcpy count from 1088 to 609 with my setup and gcc 3.4.3.
> > (kernel 2.6.12-rc1, running now)
> 
> What do you mean, 'reduced'?
> 
> (/me is checking....)
> 
> Oh shit... It still emits half of memcpys, to be exact - for
> struct copies:
> 
> arch/i386/kernel/process.c:
> 
> int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
>         unsigned long unused,
>         struct task_struct * p, struct pt_regs * regs)
> {
>         struct pt_regs * childregs;
>         struct task_struct *tsk;
>         int err;
> 
>         childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p->thread_info)) - 1;
>         *childregs = *regs;
>         ^^^^^^^^^^^^^^^^^^^
>         childregs->eax = 0;
>         childregs->esp = esp;
> 
> # make arch/i386/kernel/process.s
> 
> copy_thread:
>         pushl   %ebp
>         movl    %esp, %ebp
>         pushl   %edi
>         pushl   %esi
>         pushl   %ebx
>         subl    $20, %esp
>         movl    24(%ebp), %eax
>         movl    4(%eax), %esi
>         pushl   $60
>         leal    8132(%esi), %ebx
>         pushl   28(%ebp)
>         pushl   %ebx
>         call    memcpy  <=================
>         movl    $0, 24(%ebx)
>         movl    16(%ebp), %eax
>         movl    %eax, 52(%ebx)
>         movl    24(%ebp), %edx
>         addl    $8192, %esi
>         movl    %ebx, 516(%edx)
>         movl    %esi, -32(%ebp)
>         movl    %esi, 504(%edx)
>         movl    $ret_from_fork, 512(%edx)
> 
> Jakub, is there a way to instruct gcc to inine this copy, or better yet,
> to use user-supplied inline version of memcpy?

You can't inline struct copy as it is not function call at first place.
You can experiment with -minline-all-stringops where GCC will use it's
own memcpy implementation for this.

Honza
> --
> vda

  reply	other threads:[~2005-04-01 21:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-29 14:37 Denis Vlasenko
2005-03-29 15:06 ` Richard Guenther
2005-03-29 15:08 ` Nathan Sidwell
2005-03-29 15:13 ` Jakub Jelinek
2005-03-29 15:42   ` Andrew Pinski
2005-03-30  2:27     ` Gerold Jury
2005-03-30  6:15       ` Denis Vlasenko
2005-04-01 21:43         ` Jan Hubicka [this message]
2005-04-02 12:18           ` Denis Vlasenko
2005-04-02 12:26             ` Denis Vlasenko
2005-04-05 16:34               ` [BUG mm] "fixed" i386 memcpy inlining buggy Christophe Saout
2005-04-06 10:14                 ` Denis Vlasenko
2005-04-06 11:05                   ` Dave Korn
2005-04-06 11:13                     ` Dave Korn
2005-04-06 11:53                       ` Dave Korn
2005-04-06 11:56                         ` Dave Korn
2005-04-06 13:18                         ` Richard B. Johnson
2005-04-06 14:16                           ` Denis Vlasenko
2005-04-06 12:05                   ` Christophe Saout
2005-04-06 12:36                     ` Andrew Haley
2005-04-06 15:18                     ` Paolo Bonzini
2005-04-06 16:11                 ` Denis Vlasenko
2005-03-29 20:22 ` [PATCH] fix i386 memcpy Denis Vlasenko
2005-03-29 20:24   ` Denis Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050401214322.GA7175@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=gerold.ml@inode.at \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@ilport.com.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®