From: Joe Perches <joe@perches.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: Nicholas Mc Guire <hofrat@osadl.org>,
Michal Marek <mmarek@suse.cz>,
Masahiro Yamada <yamada.m@jp.panasonic.com>,
Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Alvin" <hpa@zytor.com>,
John Stultz <john.stultz@linaro.org>,
Andrew Hunter <ahh@google.com>, Paul Turner <pjt@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] time: allow gcc to fold constants when using msecs_to_jiffies
Date: Sun, 05 Apr 2015 19:15:02 -0700 [thread overview]
Message-ID: <1428286502.2775.92.camel@perches.com> (raw)
In-Reply-To: <20150406010025.GA5956@opentech.at>
On Mon, 2015-04-06 at 03:00 +0200, Nicholas Mc Guire wrote:
> On Sun, 05 Apr 2015, Joe Perches wrote:
>
> > On Sun, 2015-04-05 at 09:23 +0200, Nicholas Mc Guire wrote:
> > > The majority of the msecs_to_jiffies() users in the kernel are passing in
> > > constants which would allow gcc to do constant folding by checking with
> > > __builtin_constant_p() in msecs_to_jiffies().
> > >
> > > The original msecs_to_jiffies is renamed to __msecs_to_jiffies and aside
> > > from the removal of the check for negative values being moved out, is
> > > unaltered.
> >
> > At least for gcc 4.9, this doesn't allow the compiler
> > to optimize / precalculation msecs_to_jiffies calls
> > with a constant.
> >
> > This does: (on top of your patch x86-64 defconfig)
> >
> > $ size vmlinux.o.*
> > text data bss dec hex filename
> > 11770523 1505971 1018454 14294948 da1fa4 vmlinux.o.next-b0a12fb5bc8
> > 11770530 1505971 1018454 14294955 da1fab vmlinux.o.next-b0a12fb5bc8-inline
> > 11768734 1505971 1018454 14293159 da18a7 vmlinux.o.next-b0a12fb5bc8-macro
> >
> > I think this should still move the if (m) < 0 back into the
> > original __msecs_to_jiffies function.
> >
>
> could you check if you can reproduce the results below ?
> my assumption was that gcc would always optimize out an
> if(CONST < 0) return CONST; reducing it to the return CONST;
> only and thus this should not make any difference but Im not
> that familiar with gcc.
>
> gcc versions here are:
> for x86 gcc version 4.7.2 (Debian 4.7.2-5)
> for powerpc it is a gcc version 4.9.2 (crosstool-NG 1.20.0)
> for arm gcc version 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
>
> Procedure used:
> root@debian:~/linux-next# make distclean
> root@debian:~/linux-next# make defconfig
> root@debian:~/linux-next# make drivers/net/wireless/p54/p54usb.lst
> root@debian:~/linux-next# make drivers/net/wireless/p54/p54usb.s
>
> same setup in unpatched /usr/src/linux-next/
>
> e.g:
> root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.c
> timeout = jiffies + msecs_to_jiffies(1000);
> timeout = jiffies + msecs_to_jiffies(1000);
>
> So both calls are constants and should be optimized out if it works as
> expected.
>
> without the patch applied:
>
> root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.s
> call msecs_to_jiffies #
> call msecs_to_jiffies #
> root@debian:/usr/src/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.lst
> timeout = jiffies + msecs_to_jiffies(1000);
> e19: R_X86_64_PC32 msecs_to_jiffies+0xfffffffffffffffc
> timeout = jiffies + msecs_to_jiffies(1000);
> timeout = jiffies + msecs_to_jiffies(1000);
> fd8: R_X86_64_PC32 msecs_to_jiffies+0xfffffffffffffffc
> timeout = jiffies + msecs_to_jiffies(1000);
>
>
> with the patch applied this then gives me:
>
> root@debian:~/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.s
> root@debian:~/linux-next# grep msecs_to_jiffies drivers/net/wireless/p54/p54usb.lst
> timeout = jiffies + msecs_to_jiffies(1000);
> timeout = jiffies + msecs_to_jiffies(1000);
> timeout = jiffies + msecs_to_jiffies(1000);
> timeout = jiffies + msecs_to_jiffies(1000);
>
> Conversely in kernel/sched/core.c the msecs_to_jiffies is not a constant
> and the result is that it calls __msecs_to_jiffies
>
> patched:
> root@debian:~/linux-next# grep msecs_to_jiffies kernel/sched/core.s
> call __msecs_to_jiffies #
>
> unpatched:
> root@debian:/usr/src/linux-next# grep msecs_to_jiffies kernel/sched/core.s
> call msecs_to_jiffies #
>
>
> Could you check if you get these results for this test-case ?
> If this really were compiler dependant that would be very bad.
Hi Nicholas.
Your inline version has not worked with any of
x86-64 gcc 4.4, 4.6, 4.7, or 4.9
I suggest you add some lines to
lib/test_module.c/test_module_init like:
unsigned int m;
for (m = 10; m < 200; m += 10)
pr_info("msecs_to_jiffies(%u) is %lu\n",
m, msecs_to_jiffies(m));
pr_info("msecs_to_jiffies(%u) is %lu\n",
10, msecs_to_jiffies(10));
pr_info("msecs_to_jiffies(%u) is %lu\n",
100, msecs_to_jiffies(100));
pr_info("msecs_to_jiffies(%u) is %lu\n",
1000, msecs_to_jiffies(1000));
Then it's pretty easy to look at the assembly/.lst file
Your inline function doesn't allow gcc to precompute
the msecs_to_jiffies value. The macro one does for all
those gcc versions.
Try it and look at the generated .lst files with and
without the patch I sent.
cheers, Joe
next prev parent reply other threads:[~2015-04-06 2:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 7:23 [PATCH 0/3] time: use __builtin_constant_p() in msecs_to_jiffies Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 1/3] time: move timeconst.h into include/generated Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 2/3] time: allow gcc to fold constants when using msecs_to_jiffies Nicholas Mc Guire
2015-04-06 0:03 ` Joe Perches
2015-04-06 1:00 ` Nicholas Mc Guire
2015-04-06 2:15 ` Joe Perches [this message]
2015-04-06 4:26 ` Nicholas Mc Guire
2015-04-06 4:33 ` Joe Perches
2015-04-06 6:40 ` Nicholas Mc Guire
2015-04-06 7:12 ` Joe Perches
2015-04-06 7:21 ` Nicholas Mc Guire
2015-04-12 8:36 ` Nicholas Mc Guire
2015-04-05 7:23 ` [PATCH 3/3] time: update msecs_to_jiffies doc and move to kernel-doc format Nicholas Mc Guire
2015-04-05 9:33 ` [PATCH 0/3] time: use __builtin_constant_p() in msecs_to_jiffies Joe Perches
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=1428286502.2775.92.camel@perches.com \
--to=joe@perches.com \
--cc=ahh@google.com \
--cc=der.herr@hofr.at \
--cc=hofrat@osadl.org \
--cc=hpa@zytor.com \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=pjt@google.com \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=yamada.m@jp.panasonic.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.