public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Aaron Sierra <asierra@xes-inc.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] allow constant folding in msecs_to_jiffies where possible for gcc
Date: Thu, 02 Apr 2015 06:11:46 -0700	[thread overview]
Message-ID: <1427980306.23434.9.camel@perches.com> (raw)
In-Reply-To: <1427956634-32109-1-git-send-email-hofrat@osadl.org>

On Thu, 2015-04-02 at 08:37 +0200, Nicholas Mc Guire wrote:
> A number of cleanup patches where switching var * HZ / 1000
> constructs to msecs_to_jiffies(var) to ensure that all corener
> cases are handled properly. The downside of this though is that
> it now uses a function call and also was not performing
> constant folding where it was originally possible.
> 
> msecs_to_jiffies() will calculate jiffies even if constants are
> passed in that could be handled by constant folding at compile time
> using __builtin_constant_p() gcc can optimize the constant case
> again.

OK, but how could this actually work?

This code isn't visible in a module at compile time, so how
could the compiler actually optimize the function call away?

Look at the disassembly for any object that uses
msecs_to_jiffies(<constant>).

For instance: drivers/bluetooth/hci_vhci.o

	schedule_delayed_work(&data->open_timeout, msecs_to_jiffies(1000));
 60d:	bf e8 03 00 00       	mov    $0x3e8,%edi
 612:	e8 00 00 00 00       	callq  617 <vhci_open+0xc7>
			613: R_X86_64_PC32	msecs_to_jiffies-0x4

You need to make this code either a macro or static inline
in jiffies.h, and for that the kernel/timeconst.h file needs
to be available.




      reply	other threads:[~2015-04-02 13:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02  6:37 [PATCH RFC] allow constant folding in msecs_to_jiffies where possible for gcc Nicholas Mc Guire
2015-04-02 13:11 ` Joe Perches [this message]

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=1427980306.23434.9.camel@perches.com \
    --to=joe@perches.com \
    --cc=asierra@xes-inc.com \
    --cc=hofrat@osadl.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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