Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
On Mon, 23 Jul 2007, H. Peter Anvin wrote: > Linus Torvalds wrote: > > > > On Mon, 23 Jul 2007, Satyam Sharma wrote: > >> * The "I" constraint modifier is applicable only to immediate-value > >> operands, > >> and combining it with "r" is bogus. > > > > This is wrong too. > > > > The whole point of a "Ir" modifier is to say that the instruction takes > > *either* an "I" or an "r". > > > > Andrew - the ones I've looked at were all wrong. Please don't take this > > series. > > > > Incidentally, I just noticed the x86-64 bitops have "dIr" as their > constraint set. "d" would normally be redundant with "r", and as far as > I know, gcc doesn't prefer one over the other without having "?" or "!" > as part of the constraint, so is is "d" a stray or is there some meaning > behind it? Yup, I had noticed that myself. We would need to use "J" if we want to limit the offsets to 0..63, but "d" sounds weird / stray indeed, unless there's yet another undocumented/wrongly-documented mystery behind this one too ... (I'd like to know even if that's the case, obviously). Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
Linus Torvalds wrote: > > On Mon, 23 Jul 2007, Satyam Sharma wrote: >> * The "I" constraint modifier is applicable only to immediate-value operands, >> and combining it with "r" is bogus. > > This is wrong too. > > The whole point of a "Ir" modifier is to say that the instruction takes > *either* an "I" or an "r". > > Andrew - the ones I've looked at were all wrong. Please don't take this > series. > Incidentally, I just noticed the x86-64 bitops have "dIr" as their constraint set. "d" would normally be redundant with "r", and as far as I know, gcc doesn't prefer one over the other without having "?" or "!" as part of the constraint, so is is "d" a stray or is there some meaning behind it? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
On Monday 23 July 2007 20:14:52 Satyam Sharma wrote: > On Mon, 23 Jul 2007, Linus Torvalds wrote: > > > On Mon, 23 Jul 2007, Satyam Sharma wrote: > > > > > > * The "I" constraint modifier is applicable only to immediate-value > > > operands, > > > and combining it with "r" is bogus. > > > > This is wrong too. > > > > The whole point of a "Ir" modifier is to say that the instruction takes > > *either* an "I" or an "r". > > Yup, sorry about this one, Andi pointed this out earlier. But the "I" > must still go I think, for the third reason in that changelog -- it > unnecessarily limits the bit offset to 0..31, but (at least from the > comment up front in that file) we do allow arbitrarily large @nr (upto > 255, of course, these instructions won't take anything greater than that). As HPA pointed out that would risk not being correctly assembled by at least some binutils versions > > Andrew - the ones I've looked at were all wrong. Please don't take this > > series. > > I think I'll rescind the series anyway, a lot of patches turned out to > be wrong -- some due to mis-reading / incorrect gcc docs, others due to > other reasons ... this was just something I did thinking of as a cleanup > anyway, so I don't intend to push or correct this or anything. cpumask_t/nodemask_t bitmap optimizations would be useful. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
H. Peter Anvin wrote: > > "I" is correct. The Intel documentation on this is highly confusing > (and has bugs in it), but it does unambiguously state: > > "Some assemblers support immediate bit offsets larger than 31 by using > the immediate bit offset field in combination with the displacement > field in the memory operand ... The processor will ignore the high-order > bits if they are not zero." AMD processors might be different for all I > know. > > So unless gas is capable of doing this transformation (and it's not as > of binutils-2.17.50.0.6) "I" is what's needed here. > Just tested it on a K8 machine; AMD behaves the same way. So "I" is correct, and changing it to "N" would introduce a bug. The only way to optimize this is by using __builtin_constant_p() and adjust the offset appropriately. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
On Mon, 23 Jul 2007, Linus Torvalds wrote: > On Mon, 23 Jul 2007, Satyam Sharma wrote: > > > > * The "I" constraint modifier is applicable only to immediate-value > > operands, > > and combining it with "r" is bogus. > > This is wrong too. > > The whole point of a "Ir" modifier is to say that the instruction takes > *either* an "I" or an "r". Yup, sorry about this one, Andi pointed this out earlier. But the "I" must still go I think, for the third reason in that changelog -- it unnecessarily limits the bit offset to 0..31, but (at least from the comment up front in that file) we do allow arbitrarily large @nr (upto 255, of course, these instructions won't take anything greater than that). > Andrew - the ones I've looked at were all wrong. Please don't take this > series. I think I'll rescind the series anyway, a lot of patches turned out to be wrong -- some due to mis-reading / incorrect gcc docs, others due to other reasons ... this was just something I did thinking of as a cleanup anyway, so I don't intend to push or correct this or anything. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
Andi Kleen wrote: >> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had >> just written a test program that used "Ir" with an automatic variable >> defined in the inline function (as is the case with these bitops) and >> observed that even when I gave > 32 values, it would still work -- hence >> my conclusion. >> >> However, the patch still stands, does it not? [ I will modify the >> changelog, obviously. ] The thing is that we don't want to limit >> @nr to <= 31 in the first place, or am I wrong again? :-) > > These bit operations only allow 8 bit immediates, so 0..255 would > be correct. N might work from the 4.1 docs, but I don't know if it works > in all old supported gccs (3.2+) > > However I is definitely not wrong and most bit numbers are small anyways. > "I" is correct. The Intel documentation on this is highly confusing (and has bugs in it), but it does unambiguously state: "Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset field in combination with the displacement field in the memory operand ... The processor will ignore the high-order bits if they are not zero." AMD processors might be different for all I know. So unless gas is capable of doing this transformation (and it's not as of binutils-2.17.50.0.6) "I" is what's needed here. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
On Mon, 23 Jul 2007, Satyam Sharma wrote: > > * The "I" constraint modifier is applicable only to immediate-value operands, > and combining it with "r" is bogus. This is wrong too. The whole point of a "Ir" modifier is to say that the instruction takes *either* an "I" or an "r". Andrew - the ones I've looked at were all wrong. Please don't take this series. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
> > > Whoa, thanks for explaining that to me -- I didn't know, obviously. I had > > just written a test program that used "Ir" with an automatic variable > > defined in the inline function (as is the case with these bitops) and > > observed that even when I gave > 32 values, it would still work -- hence > > my conclusion. > > > > However, the patch still stands, does it not? [ I will modify the > > changelog, obviously. ] The thing is that we don't want to limit > > @nr to <= 31 in the first place, or am I wrong again? :-) > > These bit operations only allow 8 bit immediates, so 0..255 would > be correct. N might work from the 4.1 docs, but I don't know if it works > in all old supported gccs (3.2+) 'N' constraint was there pretty much forever, originally intended for in/out operands. It is in 2.95 docs http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC175 Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
> Whoa, thanks for explaining that to me -- I didn't know, obviously. I had > just written a test program that used "Ir" with an automatic variable > defined in the inline function (as is the case with these bitops) and > observed that even when I gave > 32 values, it would still work -- hence > my conclusion. > > However, the patch still stands, does it not? [ I will modify the > changelog, obviously. ] The thing is that we don't want to limit > @nr to <= 31 in the first place, or am I wrong again? :-) These bit operations only allow 8 bit immediates, so 0..255 would be correct. N might work from the 4.1 docs, but I don't know if it works in all old supported gccs (3.2+) However I is definitely not wrong and most bit numbers are small anyways. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
> On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
> > From: Satyam Sharma <[EMAIL PROTECTED]>
> >
> > [2/8] i386: bitops: Rectify bogus "Ir" constraints
> >
> > The "I" constraint (on the i386 platform) is used to restrict constants to
> > the 0..31 range, for use with instructions that must deal with bit numbers.
>
> It means I or r, not I modified by r. This means either a immediate constant
> 0..31 or a register, which is correct.
>
> % cat t18.c
>
> f()
> {
> asm("xxx %0" :: "rI" (10));
> asm("yyy %0" :: "rI" (100));
> }
> % gcc -O2 -S t18.c
> % cat t18.s
> ...
> f:
> .LFB2:
> #APP
> xxx $10
> #NO_APP
> movl$100, %eax
> #APP
> yyy %eax
> #NO_APP
> ret
> .LFE2:
> ...
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
just written a test program that used "Ir" with an automatic variable
defined in the inline function (as is the case with these bitops) and
observed that even when I gave > 32 values, it would still work -- hence
my conclusion.
However, the patch still stands, does it not? [ I will modify the
changelog, obviously. ] The thing is that we don't want to limit
@nr to <= 31 in the first place, or am I wrong again? :-)
Thanks,
Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
> From: Satyam Sharma <[EMAIL PROTECTED]>
>
> [2/8] i386: bitops: Rectify bogus "Ir" constraints
>
> The "I" constraint (on the i386 platform) is used to restrict constants to
> the 0..31 range, for use with instructions that must deal with bit numbers.
It means I or r, not I modified by r. This means either a immediate constant
0..31 or a register, which is correct.
% cat t18.c
f()
{
asm("xxx %0" :: "rI" (10));
asm("yyy %0" :: "rI" (100));
}
% gcc -O2 -S t18.c
% cat t18.s
...
f:
.LFB2:
#APP
xxx $10
#NO_APP
movl$100, %eax
#APP
yyy %eax
#NO_APP
ret
.LFE2:
...
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] i386: bitops: Rectify bogus "Ir" constraints
From: Satyam Sharma <[EMAIL PROTECTED]> [2/8] i386: bitops: Rectify bogus "Ir" constraints The "I" constraint (on the i386 platform) is used to restrict constants to the 0..31 range, for use with instructions that must deal with bit numbers. However: * The "I" constraint modifier is applicable only to immediate-value operands, and combining it with "r" is bogus. * gcc will just ignore "I" if we specify "Ir" anyway and treat it same as "r". * Bitops in Linux allow @nr to be arbitrarily large anyway, so we don't want to restrict ourselves to @nr < 32 in the first place. So just kill the bogus "I" constraint modifier. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Cc: David Howells <[EMAIL PROTECTED]> Cc: Nick Piggin <[EMAIL PROTECTED]> --- include/asm-i386/bitops.h | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h index ba8e4bb..17a302d 100644 --- a/include/asm-i386/bitops.h +++ b/include/asm-i386/bitops.h @@ -43,7 +43,7 @@ static inline void set_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX "btsl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /** @@ -63,7 +63,7 @@ static inline void __set_bit(int nr, volatile unsigned long * addr) __asm__( "btsl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /** @@ -81,7 +81,7 @@ static inline void clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX "btrl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /** @@ -101,7 +101,7 @@ static inline void __clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( "btrl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /* @@ -128,7 +128,7 @@ static inline void __change_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( "btcl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /** @@ -146,7 +146,7 @@ static inline void change_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX "btcl %1,%0" :"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); } /** @@ -166,7 +166,7 @@ static inline int test_and_set_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX "btsl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr) : "memory"); + :"r" (nr) : "memory"); return oldbit; } @@ -189,7 +189,7 @@ static inline int __test_and_set_bit(int nr, volatile unsigned long * addr) __asm__( "btsl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); return oldbit; } @@ -210,7 +210,7 @@ static inline int test_and_clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX "btrl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr) : "memory"); + :"r" (nr) : "memory"); return oldbit; } @@ -233,7 +233,7 @@ static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr) __asm__( "btrl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr)); + :"r" (nr)); return oldbit; } @@ -256,7 +256,7 @@ static inline int __test_and_change_bit(int nr, volatile unsigned long *addr) __asm__ __volatile__( "btcl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr) : "memory"); + :"r" (nr) : "memory"); return oldbit; } @@ -277,7 +277,7 @@ static inline int test_and_change_bit(int nr, volatile unsigned long* addr) __asm__ __volatile__( LOCK_PREFIX "btcl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"+m" (ADDR) - :"Ir" (nr) : "memory"); + :"r" (nr) : "memory"); return oldbit; } @@ -302,7 +302,7 @@ static inline int variable_test_bit(int nr, const volatile unsigned long * addr) __asm__ __volatile__( "btl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit) - :"m" (ADDR),"Ir" (nr)); + :"m" (ADDR),"r" (nr)); return oldbit; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
From: Satyam Sharma [EMAIL PROTECTED] [2/8] i386: bitops: Rectify bogus Ir constraints The I constraint (on the i386 platform) is used to restrict constants to the 0..31 range, for use with instructions that must deal with bit numbers. However: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. * gcc will just ignore I if we specify Ir anyway and treat it same as r. * Bitops in Linux allow @nr to be arbitrarily large anyway, so we don't want to restrict ourselves to @nr 32 in the first place. So just kill the bogus I constraint modifier. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Cc: David Howells [EMAIL PROTECTED] Cc: Nick Piggin [EMAIL PROTECTED] --- include/asm-i386/bitops.h | 26 +- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h index ba8e4bb..17a302d 100644 --- a/include/asm-i386/bitops.h +++ b/include/asm-i386/bitops.h @@ -43,7 +43,7 @@ static inline void set_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX btsl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /** @@ -63,7 +63,7 @@ static inline void __set_bit(int nr, volatile unsigned long * addr) __asm__( btsl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /** @@ -81,7 +81,7 @@ static inline void clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX btrl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /** @@ -101,7 +101,7 @@ static inline void __clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( btrl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /* @@ -128,7 +128,7 @@ static inline void __change_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( btcl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /** @@ -146,7 +146,7 @@ static inline void change_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX btcl %1,%0 :+m (ADDR) - :Ir (nr)); + :r (nr)); } /** @@ -166,7 +166,7 @@ static inline int test_and_set_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX btsl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr) : memory); + :r (nr) : memory); return oldbit; } @@ -189,7 +189,7 @@ static inline int __test_and_set_bit(int nr, volatile unsigned long * addr) __asm__( btsl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr)); + :r (nr)); return oldbit; } @@ -210,7 +210,7 @@ static inline int test_and_clear_bit(int nr, volatile unsigned long * addr) __asm__ __volatile__( LOCK_PREFIX btrl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr) : memory); + :r (nr) : memory); return oldbit; } @@ -233,7 +233,7 @@ static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr) __asm__( btrl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr)); + :r (nr)); return oldbit; } @@ -256,7 +256,7 @@ static inline int __test_and_change_bit(int nr, volatile unsigned long *addr) __asm__ __volatile__( btcl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr) : memory); + :r (nr) : memory); return oldbit; } @@ -277,7 +277,7 @@ static inline int test_and_change_bit(int nr, volatile unsigned long* addr) __asm__ __volatile__( LOCK_PREFIX btcl %2,%1\n\tsbbl %0,%0 :=r (oldbit),+m (ADDR) - :Ir (nr) : memory); + :r (nr) : memory); return oldbit; } @@ -302,7 +302,7 @@ static inline int variable_test_bit(int nr, const volatile unsigned long * addr) __asm__ __volatile__( btl %2,%1\n\tsbbl %0,%0 :=r (oldbit) - :m (ADDR),Ir (nr)); + :m (ADDR),r (nr)); return oldbit; } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[2/8] i386: bitops: Rectify bogus Ir constraints
The I constraint (on the i386 platform) is used to restrict constants to
the 0..31 range, for use with instructions that must deal with bit numbers.
It means I or r, not I modified by r. This means either a immediate constant
0..31 or a register, which is correct.
% cat t18.c
f()
{
asm(xxx %0 :: rI (10));
asm(yyy %0 :: rI (100));
}
% gcc -O2 -S t18.c
% cat t18.s
...
f:
.LFB2:
#APP
xxx $10
#NO_APP
movl$100, %eax
#APP
yyy %eax
#NO_APP
ret
.LFE2:
...
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
Hi Andi,
On Mon, 23 Jul 2007, Andi Kleen wrote:
On Monday 23 July 2007 18:05:38 Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[2/8] i386: bitops: Rectify bogus Ir constraints
The I constraint (on the i386 platform) is used to restrict constants to
the 0..31 range, for use with instructions that must deal with bit numbers.
It means I or r, not I modified by r. This means either a immediate constant
0..31 or a register, which is correct.
% cat t18.c
f()
{
asm(xxx %0 :: rI (10));
asm(yyy %0 :: rI (100));
}
% gcc -O2 -S t18.c
% cat t18.s
...
f:
.LFB2:
#APP
xxx $10
#NO_APP
movl$100, %eax
#APP
yyy %eax
#NO_APP
ret
.LFE2:
...
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had
just written a test program that used Ir with an automatic variable
defined in the inline function (as is the case with these bitops) and
observed that even when I gave 32 values, it would still work -- hence
my conclusion.
However, the patch still stands, does it not? [ I will modify the
changelog, obviously. ] The thing is that we don't want to limit
@nr to = 31 in the first place, or am I wrong again? :-)
Thanks,
Satyam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had just written a test program that used Ir with an automatic variable defined in the inline function (as is the case with these bitops) and observed that even when I gave 32 values, it would still work -- hence my conclusion. However, the patch still stands, does it not? [ I will modify the changelog, obviously. ] The thing is that we don't want to limit @nr to = 31 in the first place, or am I wrong again? :-) These bit operations only allow 8 bit immediates, so 0..255 would be correct. N might work from the 4.1 docs, but I don't know if it works in all old supported gccs (3.2+) However I is definitely not wrong and most bit numbers are small anyways. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
Whoa, thanks for explaining that to me -- I didn't know, obviously. I had just written a test program that used Ir with an automatic variable defined in the inline function (as is the case with these bitops) and observed that even when I gave 32 values, it would still work -- hence my conclusion. However, the patch still stands, does it not? [ I will modify the changelog, obviously. ] The thing is that we don't want to limit @nr to = 31 in the first place, or am I wrong again? :-) These bit operations only allow 8 bit immediates, so 0..255 would be correct. N might work from the 4.1 docs, but I don't know if it works in all old supported gccs (3.2+) 'N' constraint was there pretty much forever, originally intended for in/out operands. It is in 2.95 docs http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_16.html#SEC175 Honza - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
On Mon, 23 Jul 2007, Satyam Sharma wrote: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. This is wrong too. The whole point of a Ir modifier is to say that the instruction takes *either* an I or an r. Andrew - the ones I've looked at were all wrong. Please don't take this series. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
Andi Kleen wrote: Whoa, thanks for explaining that to me -- I didn't know, obviously. I had just written a test program that used Ir with an automatic variable defined in the inline function (as is the case with these bitops) and observed that even when I gave 32 values, it would still work -- hence my conclusion. However, the patch still stands, does it not? [ I will modify the changelog, obviously. ] The thing is that we don't want to limit @nr to = 31 in the first place, or am I wrong again? :-) These bit operations only allow 8 bit immediates, so 0..255 would be correct. N might work from the 4.1 docs, but I don't know if it works in all old supported gccs (3.2+) However I is definitely not wrong and most bit numbers are small anyways. I is correct. The Intel documentation on this is highly confusing (and has bugs in it), but it does unambiguously state: Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset field in combination with the displacement field in the memory operand ... The processor will ignore the high-order bits if they are not zero. AMD processors might be different for all I know. So unless gas is capable of doing this transformation (and it's not as of binutils-2.17.50.0.6) I is what's needed here. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
On Mon, 23 Jul 2007, Linus Torvalds wrote: On Mon, 23 Jul 2007, Satyam Sharma wrote: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. This is wrong too. The whole point of a Ir modifier is to say that the instruction takes *either* an I or an r. Yup, sorry about this one, Andi pointed this out earlier. But the I must still go I think, for the third reason in that changelog -- it unnecessarily limits the bit offset to 0..31, but (at least from the comment up front in that file) we do allow arbitrarily large @nr (upto 255, of course, these instructions won't take anything greater than that). Andrew - the ones I've looked at were all wrong. Please don't take this series. I think I'll rescind the series anyway, a lot of patches turned out to be wrong -- some due to mis-reading / incorrect gcc docs, others due to other reasons ... this was just something I did thinking of as a cleanup anyway, so I don't intend to push or correct this or anything. Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
H. Peter Anvin wrote: I is correct. The Intel documentation on this is highly confusing (and has bugs in it), but it does unambiguously state: Some assemblers support immediate bit offsets larger than 31 by using the immediate bit offset field in combination with the displacement field in the memory operand ... The processor will ignore the high-order bits if they are not zero. AMD processors might be different for all I know. So unless gas is capable of doing this transformation (and it's not as of binutils-2.17.50.0.6) I is what's needed here. Just tested it on a K8 machine; AMD behaves the same way. So I is correct, and changing it to N would introduce a bug. The only way to optimize this is by using __builtin_constant_p() and adjust the offset appropriately. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
On Monday 23 July 2007 20:14:52 Satyam Sharma wrote: On Mon, 23 Jul 2007, Linus Torvalds wrote: On Mon, 23 Jul 2007, Satyam Sharma wrote: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. This is wrong too. The whole point of a Ir modifier is to say that the instruction takes *either* an I or an r. Yup, sorry about this one, Andi pointed this out earlier. But the I must still go I think, for the third reason in that changelog -- it unnecessarily limits the bit offset to 0..31, but (at least from the comment up front in that file) we do allow arbitrarily large @nr (upto 255, of course, these instructions won't take anything greater than that). As HPA pointed out that would risk not being correctly assembled by at least some binutils versions Andrew - the ones I've looked at were all wrong. Please don't take this series. I think I'll rescind the series anyway, a lot of patches turned out to be wrong -- some due to mis-reading / incorrect gcc docs, others due to other reasons ... this was just something I did thinking of as a cleanup anyway, so I don't intend to push or correct this or anything. cpumask_t/nodemask_t bitmap optimizations would be useful. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
Linus Torvalds wrote: On Mon, 23 Jul 2007, Satyam Sharma wrote: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. This is wrong too. The whole point of a Ir modifier is to say that the instruction takes *either* an I or an r. Andrew - the ones I've looked at were all wrong. Please don't take this series. Incidentally, I just noticed the x86-64 bitops have dIr as their constraint set. d would normally be redundant with r, and as far as I know, gcc doesn't prefer one over the other without having ? or ! as part of the constraint, so is is d a stray or is there some meaning behind it? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] i386: bitops: Rectify bogus Ir constraints
On Mon, 23 Jul 2007, H. Peter Anvin wrote: Linus Torvalds wrote: On Mon, 23 Jul 2007, Satyam Sharma wrote: * The I constraint modifier is applicable only to immediate-value operands, and combining it with r is bogus. This is wrong too. The whole point of a Ir modifier is to say that the instruction takes *either* an I or an r. Andrew - the ones I've looked at were all wrong. Please don't take this series. Incidentally, I just noticed the x86-64 bitops have dIr as their constraint set. d would normally be redundant with r, and as far as I know, gcc doesn't prefer one over the other without having ? or ! as part of the constraint, so is is d a stray or is there some meaning behind it? Yup, I had noticed that myself. We would need to use J if we want to limit the offsets to 0..63, but d sounds weird / stray indeed, unless there's yet another undocumented/wrongly-documented mystery behind this one too ... (I'd like to know even if that's the case, obviously). Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
