From: Bernardo Innocenti <bernie@develer.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [PATCH] Kill div64.h dupes, parenthesize do_div() macro params
Date: Wed, 2 Jul 2003 04:24:47 +0200 [thread overview]
Message-ID: <200307020424.47629.bernie@develer.com> (raw)
In-Reply-To: <20030701173612.280d1296.akpm@digeo.com>
On Wednesday 02 July 2003 02:36, Andrew Morton wrote:
> > sorry for coming up with this patch in a short time frame, but
> > it needs to be applied in order to fix real do_div() brokenness
> > on many architectures.
>
> I included this in 2.5.73-mm2. It will percolate through after I've
> eyeballed it more thoroughly and run it past the arch maintainers.
Thank you very much Andrew! I was already thinking of contacting either
you or davem to pick that one up from me.
By the way, what do you think about getting rid of the do_div() macro
altogether? I've noticed that gcc 3.3 is quite capable of guessing the
optimal instruction pattern to use even for the generic do_div()
written in C:
rem = (unsigned long)div % (unsigned)base;
div = (unsigned long)div / (unsigned)base;
This code makes gcc select the "udivmodsi4" pattern on the m68k
backend, which computes both the quotient and remainder with a
single instruction on some architectures. The compiler is even
smart enough to optimize the case where the remainder isn't used:
if (find_reg_note (insn, REG_UNUSED, operands[3]))
return \"divu%.l %2,%0\";
else
return \"divul%.l %2,%3:%0\";
So I don't see a performance issue here. There are even places
in the kernel where do_div() is used even when the remainder
isn't used, so it's a potential performance hit (but GCC is
again smart enough to detect that dead code and discards it ;-).
If there are architectures where gcc doesn't implement divisions
correctly, this issue should be solved in gcc, not by adding a
silly macro to the kernel.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html
next prev parent reply other threads:[~2003-07-02 2:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-02 0:32 [PATCH] Kill div64.h dupes, parenthesize do_div() macro params Bernardo Innocenti
[not found] ` <20030701173612.280d1296.akpm@digeo.com>
2003-07-02 2:24 ` Bernardo Innocenti [this message]
2003-07-02 2:32 ` Andrew Morton
2003-07-02 3:15 ` Bernardo Innocenti
2003-07-02 5:12 ` Linus Torvalds
2003-07-02 7:53 ` Russell King
2003-07-02 8:14 ` Ian Molton
2003-07-02 5:09 ` Linus Torvalds
2003-07-02 7:02 ` Bernardo Innocenti
2003-07-02 7:54 ` Matti Aarnio
2003-07-02 3:36 ` Peter Chubb
2003-07-02 4:37 ` Bernardo Innocenti
2003-07-02 5:57 ` Andrea Arcangeli
2003-07-02 6:52 ` Bernardo Innocenti
2003-07-02 7:19 ` Andrea Arcangeli
2003-07-02 7:28 ` Bernardo Innocenti
2003-07-02 8:38 ` Andrea Arcangeli
2003-07-02 16:16 ` Linus Torvalds
2003-07-03 10:43 ` [PATCH] Fix do_div() for all architectures Bernardo Innocenti
2003-07-02 7:56 ` [PATCH] Kill div64.h dupes, parenthesize do_div() macro params Russell King
2003-07-02 5:06 ` Linus Torvalds
2003-07-02 14:23 ` Geert Uytterhoeven
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=200307020424.47629.bernie@develer.com \
--to=bernie@develer.com \
--cc=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.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.