On Thu, 23 Aug 2007 21:29:41 +0200, Segher Boessenkool said:
> int f(atomic_t *x)
> {
> return atomic_read(x) + atomic_read(x);
> }
> ld r0,@r0
> slli r0,#1
> jmp lr
Looks like peephole optimization at work.
pgpB5VxTDd0mQ.pgp
Description: PGP signature
> On Thu, 23 Aug 2007, Segher Boessenkool wrote:
> The combining, which I've mentioned *multiple*times* is
>
> if (atomic_read() <= 1)
>
> and dammit, if that doesn't result in a *single* instruction, the code
> generation is pure and utter crap.
>
> It should result in
>
> cmpl
On Thu, 23 Aug 2007, Segher Boessenkool wrote:
>
> This simply isn't true. The compiler *can* combine asm stuff:
Please Segher, just shut up.
The combining, which I've mentioned *multiple*times* is
if (atomic_read() <= 1)
and dammit, if that doesn't result in a *single*
Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> This simply isn't true. The compiler *can* combine asm stuff:
>
>
> typedef struct { int counter; } atomic_t;
>
> static inline __attribute__((pure)) int atomic_read(const atomic_t *v)
> {
> int x;
> asm("ld %0,@%1" : "=r"(x) :
The inline asm version has the EXACT SAME PROBLEM as the "volatile"
version has: it means that the compiler is unable to combine trivial
instructions.
This simply isn't true. The compiler *can* combine asm stuff:
typedef struct { int counter; } atomic_t;
static inline __attribute__((pure))
The inline asm version has the EXACT SAME PROBLEM as the volatile
version has: it means that the compiler is unable to combine trivial
instructions.
This simply isn't true. The compiler *can* combine asm stuff:
typedef struct { int counter; } atomic_t;
static inline __attribute__((pure))
Segher Boessenkool [EMAIL PROTECTED] wrote:
This simply isn't true. The compiler *can* combine asm stuff:
typedef struct { int counter; } atomic_t;
static inline __attribute__((pure)) int atomic_read(const atomic_t *v)
{
int x;
asm(ld %0,@%1 : =r(x) : r(v-counter),
On Thu, 23 Aug 2007, Segher Boessenkool wrote:
This simply isn't true. The compiler *can* combine asm stuff:
Please Segher, just shut up.
The combining, which I've mentioned *multiple*times* is
if (atomic_read(x) = 1)
and dammit, if that doesn't result in a *single* instruction,
On Thu, 23 Aug 2007, Segher Boessenkool wrote:
The combining, which I've mentioned *multiple*times* is
if (atomic_read(x) = 1)
and dammit, if that doesn't result in a *single* instruction, the code
generation is pure and utter crap.
It should result in
cmpl $1,offset(reg)
On Thu, 23 Aug 2007 21:29:41 +0200, Segher Boessenkool said:
int f(atomic_t *x)
{
return atomic_read(x) + atomic_read(x);
}
ld r0,@r0
slli r0,#1
jmp lr
Looks like peephole optimization at work.
pgpB5VxTDd0mQ.pgp
Description: PGP signature
On Wed, 22 Aug 2007, Segher Boessenkool wrote:
> > > I also tried to rewrite it with inline asm code, but the kernel text size
> > > bacame roughly 2kB larger. So, I prefer C version.
>
> Could you send me the source code diff between the two versions
> you tested? 2kB difference is way too
I also tried to rewrite it with inline asm code, but the kernel text
size
bacame roughly 2kB larger. So, I prefer C version.
Could you send me the source code diff between the two versions
you tested? 2kB difference is way too much, the asm version should
be smaller if anything.
You're not
Hirokazu Takata wrote:
I think the parameter of atomic_read() should have "const"
qualifier to avoid these warnings, and IMHO this modification might be
worth applying on other archs.
I agree.
Here is an additional patch to revise the previous one for m32r.
I'll incorporate this change if
Hirokazu Takata wrote:
I think the parameter of atomic_read() should have const
qualifier to avoid these warnings, and IMHO this modification might be
worth applying on other archs.
I agree.
Here is an additional patch to revise the previous one for m32r.
I'll incorporate this change if
I also tried to rewrite it with inline asm code, but the kernel text
size
bacame roughly 2kB larger. So, I prefer C version.
Could you send me the source code diff between the two versions
you tested? 2kB difference is way too much, the asm version should
be smaller if anything.
You're not
On Wed, 22 Aug 2007, Segher Boessenkool wrote:
I also tried to rewrite it with inline asm code, but the kernel text size
bacame roughly 2kB larger. So, I prefer C version.
Could you send me the source code diff between the two versions
you tested? 2kB difference is way too much, the
Hi, Chris,
From: Hirokazu Takata <[EMAIL PROTECTED]>
Date: Wed, 22 Aug 2007 10:56:54 +0900
> From: Chris Snook <[EMAIL PROTECTED]>
> Date: Mon, 13 Aug 2007 07:24:52 -0400
> > From: Chris Snook <[EMAIL PROTECTED]>
> >
> > Use volatile consistently in atomic.h on m32r.
> >
> > Signed-off-by:
From: Chris Snook <[EMAIL PROTECTED]>
Date: Mon, 13 Aug 2007 07:24:52 -0400
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Use volatile consistently in atomic.h on m32r.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Thanks,
Acked-by: Hirokazu Takata <[EMAIL PROTECTED]>
-
To unsubscribe from
Hi, Chris,
From: Hirokazu Takata [EMAIL PROTECTED]
Date: Wed, 22 Aug 2007 10:56:54 +0900
From: Chris Snook [EMAIL PROTECTED]
Date: Mon, 13 Aug 2007 07:24:52 -0400
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook [EMAIL
From: Chris Snook [EMAIL PROTECTED]
Date: Mon, 13 Aug 2007 07:24:52 -0400
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Thanks,
Acked-by: Hirokazu Takata [EMAIL PROTECTED]
-
To unsubscribe from this list:
From: Chris Snook <[EMAIL PROTECTED]>
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
--- linux-2.6.23-rc3-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m32r/atomic.h 2007-08-13
From: Chris Snook [EMAIL PROTECTED]
Use volatile consistently in atomic.h on m32r.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--- linux-2.6.23-rc3-orig/include/asm-m32r/atomic.h 2007-07-08
19:32:17.0 -0400
+++ linux-2.6.23-rc3/include/asm-m32r/atomic.h 2007-08-13
22 matches
Mail list logo
