From: "George Spelvin" <linux@horizon.com>
To: oleg@redhat.com, torvalds@linux-foundation.org
Cc: linux@horizon.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] percpu_rw_semaphore: reimplement to not block the readers unnecessarily
Date: 4 Nov 2012 03:47:43 -0500 [thread overview]
Message-ID: <20121104084743.21804.qmail@science.horizon.com> (raw)
Grand poo-bah Linus wrote:
> Now, I doubt you'll find an architecture or C compiler where this will
> actually ever make a difference, but the fact remains that you
> shouldn't use signed integers for counters like this. You should use
> unsigned, and you should rely on the well-defined modulo-2**n
> semantics.
Actually, this is another C standard undefined case that recent versions of
GCC exploit for optimization.
When using signed integers, GCC's optimizer assumes that, if b > 0,
then a + b > a.
For example, the loop:
for (i = 1; i; i++)
/* Code */
will never terminate! Feed the following to gcc -O2 and see for yourself:
extern void foo(int x);
void bar(void)
{
int i;
for (i = 0; i >= 0; i++)
foo(i);
}
here's what I get:
.file "test.c"
.text
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
pushl %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl $1, %ebx
subl $24, %esp
.cfi_def_cfa_offset 32
.p2align 4,,7
.p2align 3
.L2:
movl %ebx, (%esp)
addl $1, %ebx
call foo
jmp .L2
.cfi_endproc
.LFE0:
.size bar, .-bar
.ident "GCC: (Debian 4.7.2-4) 4.7.2"
.section .note.GNU-stack,"",@progbits
Notice the lack of test in the "jmp .L2" loop.
It can even handle more complicated cases like:
void bar(int j)
{
int i = 0;
do {
foo(i);
if (j >= 0)
i += j;
else
i -= j;
} while (i >= 0);
}
... which gcc -O3 neatly splits into two infinite loops, as if I had written:
void bar(int j)
{
int i = 0;
if (j >= 0)
for (; ; i += j)
foo(i);
else
for (; ; i -= j)
foo(i);
}
next reply other threads:[~2012-11-04 8:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-04 8:47 George Spelvin [this message]
2012-11-04 15:52 ` [PATCH 1/1] percpu_rw_semaphore: reimplement to not block the readers unnecessarily Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2012-10-16 19:56 [PATCH 1/2] brw_mutex: big read-write mutex Linus Torvalds
2012-10-17 16:59 ` Oleg Nesterov
2012-10-17 22:44 ` Paul E. McKenney
2012-10-18 16:24 ` Oleg Nesterov
2012-10-18 16:38 ` Paul E. McKenney
2012-10-18 17:57 ` Oleg Nesterov
2012-10-19 19:28 ` Paul E. McKenney
2012-10-22 23:36 ` [PATCH 0/2] fix and improvements for percpu-rw-semaphores (was: brw_mutex: big read-write mutex) Mikulas Patocka
2012-10-30 18:48 ` Oleg Nesterov
2012-10-31 19:41 ` [PATCH 0/1] percpu_rw_semaphore: reimplement to not block the readers unnecessarily Oleg Nesterov
2012-10-31 19:41 ` [PATCH 1/1] " Oleg Nesterov
2012-11-01 15:10 ` Linus Torvalds
2012-11-01 15:34 ` Oleg Nesterov
2012-11-01 15:43 ` Paul E. McKenney
2012-11-01 18:33 ` Oleg Nesterov
2012-11-02 16:18 ` Oleg Nesterov
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=20121104084743.21804.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).