Hello!
> > I guess Alexey point is that the current compiler doesn't notice that.
Rather I proposed explanation, why missing barrier does not
have any effect. 8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
On Fri, 8 Sep 2000, David Woodhouse wrote:
>[EMAIL PROTECTED] said:
>> I guess Alexey point is that the current compiler doesn't notice
>> that.
>
>I don't understand why we're bringing empirical evidence into this
>discussion. Didn't we get into the horrible mess we've already got w.r.t.
I'm
[EMAIL PROTECTED] wrote:
> > Well, now GCC does CSE across "asm" and will eliminate memory loads,
> > even though it may not move them! I suspect it always did CSE across
> > "asm" and we just never got hit by the bug.
>
> dummy_lock trick is equivalent to "memory" clobber.
For GCC 2.7.2 yes.
[EMAIL PROTECTED] said:
> I tried it with two compilers, one older than yours and one newer:
> In both cases, the memory read occurs before "zzz".
[EMAIL PROTECTED] said:
> I guess Alexey point is that the current compiler doesn't notice
> that.
I don't understand why we're bringing
[EMAIL PROTECTED] wrote:
Well, now GCC does CSE across "asm" and will eliminate memory loads,
even though it may not move them! I suspect it always did CSE across
"asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
For GCC 2.7.2 yes. For
Hello!
I guess Alexey point is that the current compiler doesn't notice that.
Rather I proposed explanation, why missing barrier does not
have any effect. 8)8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
[EMAIL PROTECTED] said:
I tried it with two compilers, one older than yours and one newer:
In both cases, the memory read occurs before "zzz".
[EMAIL PROTECTED] said:
I guess Alexey point is that the current compiler doesn't notice
that.
I don't understand why we're bringing empirical
On Fri, 8 Sep 2000, David Woodhouse wrote:
[EMAIL PROTECTED] said:
I guess Alexey point is that the current compiler doesn't notice
that.
I don't understand why we're bringing empirical evidence into this
discussion. Didn't we get into the horrible mess we've already got w.r.t.
I'm the
On Thu, 7 Sep 2000, Richard Henderson wrote:
>Perhaps. But that's not to say no future compiler won't.
I sure agree. That was my original concern w/o looking/knowing how smart
the current compiler was infact.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Sep 08, 2000 at 12:34:24AM +0200, Andrea Arcangeli wrote:
> >No it's not. We know how big the dummy_lock structure is, and
> >so might "know" that it doesn't overlap with something else.
>
> I guess Alexey point is that the current compiler doesn't notice that.
Perhaps. But that's not
On Thu, 7 Sep 2000, Richard Henderson wrote:
>No it's not. We know how big the dummy_lock structure is, and
>so might "know" that it doesn't overlap with something else.
I guess Alexey point is that the current compiler doesn't notice that.
Andrea
-
To unsubscribe from this list: send the
On Thu, Sep 07, 2000 at 09:51:26PM +0400, [EMAIL PROTECTED] wrote:
> dummy_lock trick is equivalent to "memory" clobber.
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
r~
-
To unsubscribe from this list: send the line
Hello!
> Well, now GCC does CSE across "asm" and will eliminate memory loads,
> even though it may not move them! I suspect it always did CSE across
> "asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
So that there is no real bug.
Alexey
-
To
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Common Subexpression Elimination.
>
>If the compiler sees an expression equivalent to one it evaluated
>earlier, there is no need to evaluate it a second time.
>
>So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice.
I didn't know the
> "andrea" == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
andrea> On Thu, 7 Sep 2000, Jamie Lokier wrote:
>> Well, now GCC does CSE across "asm" and will eliminate memory loads,
andrea> What is "CSE"?
Common Subexpresion Elimination. You can get a lot of info in "The
Dragon book".
Andrea Arcangeli wrote:
> >Well, now GCC does CSE across "asm" and will eliminate memory loads,
>
> What is "CSE"?
Common Subexpression Elimination.
If the compiler sees an expression equivalent to one it evaluated
earlier, there is no need to evaluate it a second time.
So "a = x+x; b = x+x"
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
>.ident "GCC: (GNU)
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Yes, it does.
Nice.
>.ident "GCC: (GNU) 2.96 2724 (experimental)"
>
>>From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
Andrea Arcangeli wrote:
> >int *p;
> >int func()
> >{
> > int x;
> > x = *p;
> > __asm__ __volatile__ ("" : : : "memory");
> > x = *p;
> > return x;
> >}
>
> Defintely none difference here (-fstrict-aliasing doesn't change anything
> either).
>
> andrea@inspiron:~ > gcc -v
> Reading specs
Andrea Arcangeli wrote:
> Said that if your compiler puts the read before the spin_lock without the
> memory clobber, it is allowed to do that, and in such case you would proof
> it was a real world bug (not just a "documentation" one).
Yes, it does.
> Or maybe your testcase was a bit different
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>Well, now GCC does CSE across "asm" and will eliminate memory loads,
What is "CSE"?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>int *p;
>int func()
>{
> int x;
> x = *p;
> __asm__ __volatile__ ("" : : : "memory");
> x = *p;
> return x;
>}
>
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ > gcc -v
Reading specs from
Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really
[EMAIL PROTECTED] wrote:
> Just hint. I remember the time when "memory" clobber option
> was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
> To all that I understand, "asm" (like function calls) implied barrier
> that time and constraints and clobber option were used only
Linus Torvalds wrote:
> Change it to something like
>
> __asm__("":"=r" (x):"0" (x));
>
> and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
> Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> It's ok for the compiler to do that (given we don't know what "volatile"
> means anyway :-). But it does have implications for spin_lock:
> spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>
> ps. There is a _clobber_ for memory, but no way to say "this asm _reads_
> arbitrary memory". __volatile__ may be filling that role though.
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That
Linus Torvalds wrote:
> "volatile" should be equivalent to clobbering memory, although the gcc
> manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
Andrea Arcangeli wrote:
> >>int a = *p;
> >>__asm__ __volatile__("" : :);
> >>a = *p;
> >>
> >> (to do two explicit reads)
> >
> >Sorry, that does just one read, kgcc (old stable gcc) and also with
> >gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
>
> I
On Thu, 7 Sep 2000, Jamie Lokier wrote:
> asm *__volatile__* seems to make no difference. I've tried a few things.
>
> Andrea Arcangeli wrote:
> > Maybe we can rely on the __volatile__ statement of the asm that will
> > enforce that if we write:
> >
> > *p = 0;
> > __asm__
Hello!
> tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
> implement semantics of the "memory" clobber fast
Just hint. I remember the time when "memory" clobber option
was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
To all that I understand,
On Thu, 7 Sep 2000, Jamie Lokier wrote:
>asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
>
>Andrea Arcangeli wrote:
>> Maybe we can rely on the __volatile__ statement of the asm that will
>> enforce that if we write:
>>
>> *p =
On Thu, 7 Sep 2000, Andrea Arcangeli wrote:
> On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
> I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
> memory (it looks necessary to
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
> Maybe we can rely on the __volatile__ statement of the asm that will
> enforce that if we write:
>
> *p = 0;
> __asm__ __volatile__("" : :);
> *p = 1;
>
> in the assembler we'll
On Thu, 7 Sep 2000, Franz Sirl wrote:
>In short terms:
>
>- __volatile__ assures that the code isn't reordered against other
>__volatile__ and isn't hoisted out of loops, nothing else
>- the "memory" clobber makes sure the asm isn't reordered against other
>memory accesses
Ok. That's all I
At 17:03 07.09.00, Andrea Arcangeli wrote:
>On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>
> >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
> >"memory".
>
>I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
>memory (it looks necessary to make sure
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
>barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
>"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the
Hello!
tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
implement semantics of the "memory" clobber fast
Just hint. I remember the time when "memory" clobber option
was _absent_ in gcc. And we managed to compile kernel with such gcc. 8)
To all that I understand, "asm"
On Thu, 7 Sep 2000, Jamie Lokier wrote:
Well, now GCC does CSE across "asm" and will eliminate memory loads,
What is "CSE"?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Thu, 7 Sep 2000, Jamie Lokier wrote:
Common Subexpression Elimination.
If the compiler sees an expression equivalent to one it evaluated
earlier, there is no need to evaluate it a second time.
So "a = x+x; b = x+x" will evaluate "x+x" just once and store it twice.
I didn't know the name of
"andrea" == Andrea Arcangeli [EMAIL PROTECTED] writes:
andrea On Thu, 7 Sep 2000, Jamie Lokier wrote:
Well, now GCC does CSE across "asm" and will eliminate memory loads,
andrea What is "CSE"?
Common Subexpresion Elimination. You can get a lot of info in "The
Dragon book".
Later, Juan.
--
Hello!
Well, now GCC does CSE across "asm" and will eliminate memory loads,
even though it may not move them! I suspect it always did CSE across
"asm" and we just never got hit by the bug.
dummy_lock trick is equivalent to "memory" clobber.
So that there is no real bug.
Alexey
-
To
On Thu, Sep 07, 2000 at 09:51:26PM +0400, [EMAIL PROTECTED] wrote:
dummy_lock trick is equivalent to "memory" clobber.
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
r~
-
To unsubscribe from this list: send the line
On Thu, 7 Sep 2000, Richard Henderson wrote:
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
I guess Alexey point is that the current compiler doesn't notice that.
Andrea
-
To unsubscribe from this list: send the line
On Fri, Sep 08, 2000 at 12:34:24AM +0200, Andrea Arcangeli wrote:
No it's not. We know how big the dummy_lock structure is, and
so might "know" that it doesn't overlap with something else.
I guess Alexey point is that the current compiler doesn't notice that.
Perhaps. But that's not to
On Thu, 7 Sep 2000, Richard Henderson wrote:
Perhaps. But that's not to say no future compiler won't.
I sure agree. That was my original concern w/o looking/knowing how smart
the current compiler was infact.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
Andrea Arcangeli wrote:
int a = *p;
__asm__ __volatile__("" : :);
a = *p;
(to do two explicit reads)
Sorry, that does just one read, kgcc (old stable gcc) and also with
gcc-2.96. Type aliasing on/off makes no difference to the number of reads.
I wrote the above not
Linus Torvalds wrote:
"volatile" should be equivalent to clobbering memory, although the gcc
manual pages are certainly not very verbose on the issue.
It isn't. Try the following with/without the memory clobber:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : :
On Thu, 7 Sep 2000, Jamie Lokier wrote:
It's ok for the compiler to do that (given we don't know what "volatile"
means anyway :-). But it does have implications for spin_lock:
spin_lock must say that it clobbers memory.
Yup. We should just fix that.
Linus
-
To
Linus Torvalds wrote:
Change it to something like
__asm__("":"=r" (x):"0" (x));
and the "volatile" should matter.
Yes it does. Without "volatile", the asm disappears :-)
Not for memory references, perhaps. But for the movement issues.
The compiler isn't moving memory references
On Thu, 7 Sep 2000, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure
On Thu, 7 Sep 2000, Franz Sirl wrote:
In short terms:
- __volatile__ assures that the code isn't reordered against other
__volatile__ and isn't hoisted out of loops, nothing else
- the "memory" clobber makes sure the asm isn't reordered against other
memory accesses
Ok. That's all I wanted
Linus Torvalds wrote:
Nope. "memory" fills that role too. Remember: "memory" doesn't actually
say "this clobbers all memory". That would be silly: an asm that just
wipes all memory would not be a very useful asm (or rather, it would have
just _one_ use: "execve()"). So "memory" really says
On Thu, 7 Sep 2000, Jamie Lokier wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
At 17:03 07.09.00, Andrea Arcangeli wrote:
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the
Andrea Arcangeli wrote:
Said that if your compiler puts the read before the spin_lock without the
memory clobber, it is allowed to do that, and in such case you would proof
it was a real world bug (not just a "documentation" one).
Yes, it does.
Or maybe your testcase was a bit different
Andrea Arcangeli wrote:
int *p;
int func()
{
int x;
x = *p;
__asm__ __volatile__ ("" : : : "memory");
x = *p;
return x;
}
Defintely none difference here (-fstrict-aliasing doesn't change anything
either).
andrea@inspiron:~ gcc -v
Reading specs from
On Thu, 7 Sep 2000, Jamie Lokier wrote:
Yes, it does.
Nice.
.ident "GCC: (GNU) 2.96 2724 (experimental)"
From the Red Hat 7 beta.
Ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
On Thu, 7 Sep 2000, Jamie Lokier wrote:
I tried it with two compilers, one older than yours and one newer:
So maybe I'm just been unlucky/lucky (depends on the point of view :) or
maybe we patched something I'm not aware of to make the kernel to compile
right.
.ident "GCC: (GNU)
asm *__volatile__* seems to make no difference. I've tried a few things.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
__asm__ __volatile__("" : :);
*p = 1;
in the assembler we'll then
On Thu, 7 Sep 2000, Jamie Lokier wrote:
asm *__volatile__* seems to make no difference. I've tried a few things.
It makes a difference, see below.
Andrea Arcangeli wrote:
Maybe we can rely on the __volatile__ statement of the asm that will
enforce that if we write:
*p = 0;
On Mon, 4 Sep 2000, Andrea Arcangeli wrote:
barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber
"memory".
I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
memory (it looks necessary to make sure the compiler doesn't delay to
write data to the memory
On Tue, 29 Aug 2000, Andrea Arcangeli wrote:
>I'd prefer to have things like UnlockPage implemented as the architecture
>prefers (with a safe SMP common code default) instead of exporting zillons
I changed idea. I'd preferred to implement a mechanism that allows to
implement common code taking
On Tue, 29 Aug 2000, Andrea Arcangeli wrote:
I'd prefer to have things like UnlockPage implemented as the architecture
prefers (with a safe SMP common code default) instead of exporting zillons
I changed idea. I'd preferred to implement a mechanism that allows to
implement common code taking
65 matches
Mail list logo
