From: Muli Ben-Yehuda <mulix@mulix.org>
To: Miles Bader <miles@gnu.org>
Cc: Jamie Lokier <jamie@shareable.org>, Andrew Morton <akpm@osdl.org>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] document optimizing macro for translating PROT_ to VM_ bits
Date: Tue, 30 Sep 2003 12:24:03 +0300 [thread overview]
Message-ID: <20030930092403.GR29313@actcom.co.il> (raw)
In-Reply-To: <buoad8m3dvn.fsf@mcspd15.ucom.lsi.nec.co.jp>
[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]
On Tue, Sep 30, 2003 at 04:59:56PM +0900, Miles Bader wrote:
> Muli Ben-Yehuda <mulix@mulix.org> writes:
> > Ok, that's a pretty convincing argument for scraping that
> > version. I'll rewrite it to evaluate the arguments at compile time if
> > they're constants, which they are, in our case. Unless someone else
> > beats me to it, of course ;-)
>
> What's wrong with the macro version? The presence of a __ prefix
> suggests that it's only used in controlled circumstances anyway, so is
> validity-checking on the bit arguments really worthwhile?
I like code that is "future proof", especially when it doesn't cost
anything. These examples generate identical code for me with gcc-3.3
and almost identical code with gcc-2.96 (one instruction difference,
and I can't tell which is faster), and the inline function barfs when
its arguments are incorrect during compile time, whereas the macro
will silently give you the wrong results. How does it fare on your
arch?
#include <stdio.h>
#include <assert.h>
#define BUG_ON(x) assert(x)
/* compiler trap for assert_single_bit. */
extern void __assert_single_bit_failed_dont_exist(void);
/*
* assert that only a single bit is on in 'bit'
*/
#define assert_single_bit(bit) do { \
if (__builtin_constant_p(bit)) { \
if ((bit & (bit -1))) \
__assert_single_bit_failed_dont_exist(); \
} else \
BUG_ON(!(bit & (bit - 1))); \
} while(0)
/*
* Optimisation function. It is equivalent to:
* (x & bit1) ? bit2 : 0
* but this version is faster.
* ("bit1" and "bit2" must be single bits).
*/
static inline unsigned long
inline_calc_vm_trans(unsigned long x, unsigned long bit1, unsigned long bit2)
{
assert_single_bit(bit1);
assert_single_bit(bit2);
return ((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1))
: ((x) & (bit1)) / ((bit1) / (bit2)));
}
/* Optimisation macro. */
#define macro_calc_vm_trans(x,bit1,bit2) \
((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
: ((x) & (bit1)) / ((bit1) / (bit2)))
int test3(unsigned long arg)
{
return macro_calc_vm_trans(arg, 0x20, 0x80);
}
int test4(unsigned long arg)
{
return inline_calc_vm_trans(arg, 0x20, 0x80);
}
int main(void)
{
int l1 = test4(~0UL);
int l2 = test3(~0UL);
return l1 & l2; /* don't optimize them out */
}
gcc-2.96:
test3:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %eax
andl $32, %eax
sall $2, %eax
popl %ebp
ret
test4:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
andl $32, %eax
sall $2, %eax
leave
ret
--
Muli Ben-Yehuda
http://www.mulix.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-09-30 9:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-29 9:06 [PATCH] document optimizing macro for translating PROT_ to VM_ bits Muli Ben-Yehuda
2003-09-29 15:34 ` Jamie Lokier
2003-09-29 15:51 ` Valdis.Kletnieks
2003-09-29 17:11 ` Jamie Lokier
2003-09-29 17:25 ` Maciej Zenczykowski
2003-09-30 2:15 ` Miles Bader
2003-09-30 7:10 ` Muli Ben-Yehuda
2003-09-30 7:34 ` Miles Bader
2003-09-30 7:41 ` Muli Ben-Yehuda
2003-09-30 7:59 ` Miles Bader
2003-09-30 9:24 ` Muli Ben-Yehuda [this message]
2003-09-30 10:00 ` Miles Bader
2003-09-30 10:06 ` Miles Bader
2003-10-02 11:37 ` Muli Ben-Yehuda
2003-09-30 10:35 ` Thomas Schlichter
2003-09-30 8:02 ` Frédéric St-Martin
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=20030930092403.GR29313@actcom.co.il \
--to=mulix@mulix.org \
--cc=akpm@osdl.org \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miles@gnu.org \
/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