On Mon, Oct 29, 2007 at 10:43:13 +0300, Tomash Brechko wrote:
> I think most pro-volatile people didn't understood the meaning of
> several papers in the Internet that say you have to use volatile.
And some don't understand the true purposes of volatile itself. In
the code below
volatile int
On 10/29/07, Tomash Brechko <[EMAIL PROTECTED]> wrote:
> But if *v is simply shared, do all stores to it matter? No, only the
> final value is relevant.
Actually it depends, it might matter. If you have a loop checking the
value of *v on a different thread and it does not change until this
loop
> volatile int *v = (int *) 0xdeadbeef;
>
> void
> f()
> {
> int i;
> for (i = 0; i < N; ++i)
> *v = 1;
> }
>
>
> _all_ N stores matter. Why? Because v may point to the device I/O
> port, and the device may _count_ those writes among other things.
>
> But if *v is simply s
On Mon, Oct 29, 2007 at 09:12:09 +0100, Eric Botcazou wrote:
> Define "final value".
The value that will be seen by other threads after they synchronize
memory (with pthread_mutex_lock(), for instance).
--
Tomash Brechko
On Mon, Oct 29, 2007 at 01:08:22 -0700, Andrew Pinski wrote:
> On 10/29/07, Tomash Brechko <[EMAIL PROTECTED]> wrote:
> > But if *v is simply shared, do all stores to it matter? No, only the
> > final value is relevant.
>
> Actually it depends, it might matter. If you have a loop checking the
>
On Mon, Oct 29, 2007 at 11:42:10 +0300, Tomash Brechko wrote:
> It means that the current thread is free to cache the value in the
> register as long as it knows no other thread can access it (i.e. as
> long as it holds corresponding mutex).
And because your next question will be "how the compiler
> And because your next question will be "how the compiler will know the
> corresponding mutex", the answer is: it can't, that's why "opaque
> function" rules come to play.
Right, so please define more or less formally what the "final value" is from
the viewpoint of the current thread, this is th
> The value that will be seen by other threads after they synchronize
> memory (with pthread_mutex_lock(), for instance).
What does it mean from the viewpoint of the current thread?
--
Eric Botcazou
On Mon, Oct 29, 2007 at 09:31:13 +0100, Eric Botcazou wrote:
> > The value that will be seen by other threads after they synchronize
> > memory (with pthread_mutex_lock(), for instance).
>
> What does it mean from the viewpoint of the current thread?
It means that the current thread is free to ca
On Mon, Oct 29, 2007 at 09:50:16 +0100, Eric Botcazou wrote:
> Right, so please define more or less formally what the "final value" is from
> the viewpoint of the current thread, this is the crux of the matter.
OK, formally there's no "final" value from current thread's POV, only
the "current" va
On Mon, Oct 29, 2007 at 11:55:25 +0300, Tomash Brechko wrote:
> OK, formally there's no "final" value from current thread's POV, only
> the "current" value. "Final" only matters from other thread's POV,
> like "this is the last value that was produced by another thread
> before it released the mut
hi,
UINT64 a64; // UINT64 has been typedefed as long long unsigned int
UINT32 a32, b32;
a32 = x; // some value
b32 = y; // some value
a64 = a32 * b32;
a64 += a32 + b32;
Is it necessary to type-cast both a32 and b32 to make above statements
to work as expected? Without casting, I find that additi
> "skaller" == skaller <[EMAIL PROTECTED]> writes:
skaller> Since 'a' here is sharable, the function can assume it is not
skaller> aliased in a register, load and increment it and store it
skaller> back.
skaller> It doesn't matter then, whether there is a mutex or not. In
skaller> fact, it
On Mon, Oct 29, 2007 at 12:04:14 +0300, Tomash Brechko wrote:
> Rather, "...before it released the mutex, and we acuired the same
> mutex". But it may be the same thread actually, so "final value" is
> the value that is seen by the thread at the beginning of excusive
> access to the object. It is
Richard Guenther writes:
> On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > Unfortunately it seems that the POSIX standard for threads say that as long
> > as access to a shared variable is protected by a mutex there is no need to
> > use 'volatile'.
>
> Which is a very unpracticab
On Mon, Oct 29, 2007 at 03:05:32PM +0530, kum wrote:
>
> Is it necessary to type-cast both a32 and b32 to make above statements
> to work as expected? Without casting, I find that addition works while
> the multiplication does not. Is there a compiler option to make this
> work without casting? I
[this is not a question for the GCC developers list]
Kumaresh> Is it necessary to type-cast both a32 and b32 to make above
Kumaresh> statements to work as expected?
Yes.
Kumaresh> Without casting, I find that addition works while the
Kumaresh> multiplication does not.
Addition is not supposed t
On Mon, 2007-10-29 at 10:37 +0100, Samuel Tardieu wrote:
> > "skaller" == skaller <[EMAIL PROTECTED]> writes:
> with (x86):
>
> movla, %eax
> cmpl$1, 4(%esp)
> sbbl$-1, %eax
> movl%eax, a
>
> There is clearly a race condition if you have mult
One thing that seems missing from this thread is any quantitative
analysis of the value of this optimization. Although justifiable
from a formal point of view, whenever an optimization causes
difficulties for a significant number of users, it is important
to justify the optimization with clear dat
David Miller wrote:
From: Darryl Miles <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 04:53:49 +
What are the issues with "speculative loads" ?
The conditional might be protecting whether the pointer is valid and
can be dereferenced at all.
This then leads into the question. Is a pointer a
skaller wrote:
Ah .. ok I think I finally see. Thanks! The code ensures
well definedness by checking the establishment of the
required invariant and dynamically chosing whether or not
to do the access on that basis .. and the optimisation
above defeats that by lifting the access out of the
condit
On Mon, Oct 29, 2007 at 12:54:22 +0100, Andi Kleen wrote:
> See http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html for a test case
> that shows where it can go horrible wrong (optimized code significantly
> slower than unoptimized code) Admittedly it is a constructed
> one, but I don't think it is th
Darryl Miles wrote:
This then leads into the question. Is a pointer allowed to be invalid.
I'm sure I have read a comment on this before, along the line of the
spec says it must be valid or a certain number of other values (like
zero or one past being valid). But I can not cite chapter and
Tomash Brechko <[EMAIL PROTECTED]> writes:
> - optimization in question might well turn out to be misoptimization
> for anything but microbenchmarks (read LKML for cache flush/dirty
> page issues).
See http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html for a test case
that shows where it
On Mon, Oct 29, 2007 at 03:14:06PM +0300, Tomash Brechko wrote:
> On Mon, Oct 29, 2007 at 12:54:22 +0100, Andi Kleen wrote:
> > See http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html for a test case
> > that shows where it can go horrible wrong (optimized code significantly
> > slower than unoptimize
> Let's see what the results are on the now "optimal" first strategy.
Far better, but I've still a 51 min gap on a full checking bootstrap.
--
Eric Botcazou
On 10/29/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Let's see what the results are on the now "optimal" first strategy.
>
> Far better, but I've still a 51 min gap on a full checking bootstrap.
More tweaks to come.
Richard.
Hi,
On Sun, 28 Oct 2007, David Miller wrote:
> The compiler simply cannot speculatively load or store to variables with
> global visibility.
>
> Suggesting volatile is totally impractical and in fact overkill.
>
> Even basic correct single-threaded UNIX programs are broken by these
> speculat
Hi,
On Sun, 28 Oct 2007, Mark Mielke wrote:
> are not like this. Most uses require only lose ordering. The lose
> ordering is providing by a mutex or other synchronization primitive. As
> any function call might call a synchronization primitive, this would
> mean that any function call should
Hi,
On Sun, 28 Oct 2007, David Miller wrote:
> the program would have allowed them to occur, otherwise you risk
> taking exceptions.
>
> Do you really think that:
>
> the_pointer_is_valid = func(potentially_bad_pointer);
> if (the_pointer_is_valid)
> *potentially_bad_p
Michael Matz wrote:
if (condition)
*p = value;
(i.e. without any synchronization primitive or in fact anything else after
the store in the control region) and expect that the store indeed only
happens in that control region. And this expectation is misguided. Had
they written it like:
Michael Matz wrote:
Yes, and of course GCC doesn't move stores or loads over functions calls.
That's not the issue at all. The issue is, that people want to write
this:
if (condition)
*p = value;
(i.e. without any synchronization primitive or in fact anything else after
the store in th
Hi,
On Mon, 29 Oct 2007, Robert Dewar wrote:
> One thing that seems missing from this thread is any quantitative
> analysis of the value of this optimization.
Please read my mails carefully.
Ciao,
Michael.
Hi,
On Mon, 29 Oct 2007, Darryl Miles wrote:
> Don't you need the barrier before. This is to ensure it completed the
> condition test completely first before it then processed the assignment
> expression.
>
> if(condition) {
> somebarrier();
> *p = value;
> }
>
> The issue is not that the st
> I'd rather take the make the dot-zero release approach while branching
> and count on interested people fixing bugs on the branch after the
> dot-zero release. This way if nobody is interested on a particular
> release series then we can declare the dot-zero release final -
> otherwise we'd do
Michael Matz wrote:
Hi,
On Mon, 29 Oct 2007, Robert Dewar wrote:
One thing that seems missing from this thread is any quantitative
analysis of the value of this optimization.
Please read my mails carefully.
Well perhaps some emails got lost, but to be clear what I am looking
for is actual
Hi,
On Mon, 29 Oct 2007, Robert Dewar wrote:
> Well perhaps some emails got lost, but to be clear what I am looking for
> is actual data on real live large scale applications that show this
> optimization having a significant effect. I have not seen that. Yes, I
> understand that individual sm
Michael Matz wrote:
Don't you need the barrier before. This is to ensure it completed the
condition test completely first before it then processed the assignment
expression.
if(condition) {
somebarrier();
*p = value;
}
The issue is not that the store is done too late, but that a
write-acces
Michael Matz wrote:
456.hmmer is not a small benchmark, but a real world scientific
application for protein sequence analysis using hidden markov models. It
just so happens that it also is a standardized benchmark in cpu2006.
A single data point is not data in the sense I refer to. What you
On 10/28/07, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> >Thank you!
> >I'll try to check into the details when I get back home, and let you know
> > more.
> >I thought the entire GCC suite (x86_64 version) installed OK. I believe
> > I just need that suite for "-m32" to work OK.
>
>
> In August, I wrote the following about vectorized / not vectorized loops
> in HIRLAM
> (see http://hirlam.org):
>
> > $ grep 'LOOP VECTORIZED' HL_Prepare_00.html | wc -l
> > 3273
> > $ grep 'not vectorized' HL_Prepare_00.html | wc -l
> > 7845
>
> Yesterday, I performed a test with gcc-trunk-129
Benjamin Kosnik wrote:
I'd rather take the make the dot-zero release approach while branching
and count on interested people fixing bugs on the branch after the
dot-zero release. This way if nobody is interested on a particular
release series then we can declare the dot-zero release final -
o
> The only problem, is that anyone doing stage 1 work is already doing
> so in a branch, and history (at least as I remember it :-) is that
> if little johnny doesn't have a pressing need for the current
> release, he will simply keep plugging along on his branch until stage
> 1 happens, whether
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
>
> > The only problem, is that anyone doing stage 1 work is already doing
> > so in a branch, and history (at least as I remember it :-) is that
> > if little johnny doesn't have a pressing need for the current
> > release, he will simply ke
On Mon, Oct 29, 2007 at 15:53:56 +0100, Michael Matz wrote:
> No it won't, because without further information GCC can't know that a
> memory access won't trap. Ergo it will not move it out of its control
> region, exactly because it would potentially introduce traps where there
> were none bef
From: "Dave Korn" <[EMAIL PROTECTED]>
> > Better write your own compiler then.
On Sun, Oct 28, 2007 at 06:34:01PM -0700, David Miller wrote:
> If this becomes the common attitude of GCC developers, you can pretty
> much guarentee this will drive people to work on LLVM and other
> alternative co
On Mon, Oct 29, 2007 at 19:20:25 +0300, Tomash Brechko wrote:
> Good reasoning, and that's exactly what some of us are asking for.
> Please see the example:
At higher optimization levels GCC may inline f(), or not call it at
all, so below is a more complete case:
#include
#include
#include
On Sun, Oct 28, 2007 at 10:17:38PM -0700, David Miller wrote:
> From: Darryl Miles <[EMAIL PROTECTED]>
> Date: Mon, 29 Oct 2007 04:53:49 +
>
> > What are the issues with "speculative loads" ?
>
> The conditional might be protecting whether the pointer is valid and
> can be dereferenced at all
On Mon, 2007-10-29 at 11:57 +, Darryl Miles wrote:
> This then leads into the question. Is a pointer allowed to be invalid.
A variable of type X need not contain an X in C, however the
effect of any operation including assignment, copying,
or passing is undefined if the value isn't valid.
Andi Kleen <[EMAIL PROTECTED]> writes:
> Your patch would fix it too because it uses a function call, but
> it might not in the general case when the condition happens to be
> not a function call.
My patch will disable the if-conversion optimization for your example,
because the variable is not
Joe Buck wrote:
From: "Dave Korn" <[EMAIL PROTECTED]>
Better write your own compiler then.
On Sun, Oct 28, 2007 at 06:34:01PM -0700, David Miller wrote:
If this becomes the common attitude of GCC developers, you can pretty
much guarentee this will drive people to work on LLVM and other
alte
Andrew MacLeod wrote:
But yes, Id still be in favour of trying this or anything else which
might help. Cut a release branch, and simply refuse to open stage 1
until we release.
I think I prefer Richard's suggestion of not branching until we're ready
to make the .0 release. The effect should
Jason Merrill wrote:
Andrew MacLeod wrote:
But yes, Id still be in favour of trying this or anything else which
might help. Cut a release branch, and simply refuse to open stage 1
until we release.
I think I prefer Richard's suggestion of not branching until we're
ready to make the .0 releas
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Jason Merrill wrote:
> > Andrew MacLeod wrote:
> >> But yes, Id still be in favour of trying this or anything else which
> >> might help. Cut a release branch, and simply refuse to open stage 1
> >> until we release.
> >
> > I think I prefer
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> >> Sure, I think it boils down to the same thing from a conceptual point of
> >> view, but perhaps the nitty gritty details are easier if you keep it as
> >> mainline so we dont have to check everything into 2 branch
Richard Guenther wrote:
Sure, I think it boils down to the same thing from a conceptual point of
view, but perhaps the nitty gritty details are easier if you keep it as
mainline so we dont have to check everything into 2 branches. Bottom
line is you freeze development until its time to release.
On Friday 26 of October 2007 19:40:34 Joe Buck wrote:
> Some programs try to isolate the details of where the headers are by
> having one header with #ifdefs that, in turn, does the #include of
> , but many others do not.
I think you shouldn't care about implementation specific #include .
I'm usi
On 10/29/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 10/29/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > > Let's see what the results are on the now "optimal" first strategy.
> >
> > Far better, but I've still a 51 min gap on a full checking bootstrap.
>
> More tweaks to come.
I have a
Robert Dewar <[EMAIL PROTECTED]> writes:
>
> a) the standard allows the optimization (or rather does not forbid it)
Assuming it is an optimization. See
http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html
for a counter example. In general cache misses are so costly that anything
that risks introducing
Andi Kleen wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
a) the standard allows the optimization (or rather does not forbid it)
Assuming it is an optimization. See
http://gcc.gnu.org/ml/gcc/2007-10/msg00607.html
for a counter example. In general cache misses are so costly that anything
that
Hi Tomash,
> moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O0 mmap.c -o mmap
> moonlight:/tmp$ ./mmap
> GCC is the best compiler ever!
> moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O1 mmap.c -o mmap
> moonlight:/tmp$ ./mmap
> Segmentation fault
I don't see this with gcc 4.1
Hi,
On Mon, 29 Oct 2007, Tomash Brechko wrote:
> Still, I believe the example proves the general idea. It shows that
> speculative store is never safe, because every 'if' may be an 'if not
> read-only'-one.
It is safe if there's another dominating store outside the control region.
Apart fro
On Mon, 2007-10-29 at 21:03 +0100, Andi Kleen wrote:
> On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
> > Sure, well nearly every optimization has some case where it is a
> > pessimization (one interesting thing that happens is that if you
> > change the length of generated code in
> -Original Message-
> From: Andrew MacLeod [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 12:48 PM
> To: Richard Guenther
> Cc: Jason Merrill; Benjamin Kosnik; gcc@gcc.gnu.org;
> [EMAIL PROTECTED]
> Subject: Re: GCC 4.3 release schedule
> I don't think we need a 6 month r
On Mon, Oct 29, 2007 at 21:52:19 +0100, Michael Matz wrote:
> It is safe if there's another dominating store outside the control region.
> Apart from that I reluctantly agree (i.e. it's not enough if there's any
> dominating access through the pointer in question, it must be a store).
Thank you
> But shouldn't we formally define "define" first? :)
Note that I wrote "more or less formally". The definition of "volatile" in
the ISO C standard falls into this category and I'd personally trust it more
than whatever -fno-speculative-store option.
See gcc/gthr-posix.h for a proper use of "v
On Mon, Oct 29, 2007 at 08:37:52PM +0100, Duncan Sands wrote:
> Hi Tomash,
>
> > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O0 mmap.c -o mmap
> > moonlight:/tmp$ ./mmap
> > GCC is the best compiler ever!
> > moonlight:/tmp$ /usr/local/gcc-4.3-trunk/bin/gcc -O1 mmap.c -o mmap
> > m
On Mon, Oct 29, 2007 at 20:37:52 +0100, Duncan Sands wrote:
> I don't see this with gcc 4.1 or 4.2. Just a data point.
Yes, thanks for pointing this. It fails with gcc (GCC) 4.3.0 20071021
(experimental) though. It turns out that GCC 4.2 and below don't do
this optimization for pointers (even w
skaller wrote:
On Mon, 2007-10-29 at 21:03 +0100, Andi Kleen wrote:
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
Sure, well nearly every optimization has some case where it is a
pessimization (one interesting thing that happens is that if you
change the length of generated cod
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
> Sure, well nearly every optimization has some case where it is a
> pessimization (one interesting thing that happens is that if you
> change the length of generated code in *any* way you may be unlucky
> and cause a systematic instruc
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
>
> > I think I prefer Richard's suggestion of not branching until we're
> > ready to make the .0 release. The effect should be the same except
> > that people don't have to deal with checking patches in on the branch
> > vs. the trunk until
Andi Kleen wrote:
On Mon, Oct 29, 2007 at 03:51:27PM -0400, Robert Dewar wrote:
Sure, well nearly every optimization has some case where it is a
pessimization (one interesting thing that happens is that if you
change the length of generated code in *any* way you may be unlucky
and cause a syste
Snapshot gcc-4.1-20071029 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071029/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I've a fast idea.
To release now it as gcc-4.3.0 if the building of distribution's base
doesn't crashes.
To start the branch for gcc-4.4-ss.
Many linux's people start to test gcc-4.3.0 from their distributions
and to report their bugs.
Tomorrow, we will have a rocked gcc-4.3.15 quickly possible
> I think I prefer Richard's suggestion of not branching until we're
> ready to make the .0 release. The effect should be the same except
> that people don't have to deal with checking patches in on the branch
> vs. the trunk until after 4.3.0 goes out.
This would certainly make things easier. A
Robert Dewar wrote:
Yes, of course! unrolling loops is often an overall loss
Note also that excessive inlining often is a loss due to
increase in icache pressure. In Ada it is the style to
carefully mark inlinable routines with pragma Inline, and
we often find in Ada that use of -O3, which act
Richard Guenther wrote:
> Sure. I'd expect the usual release candidate or two separated by
> one or two weeks. I'd also expect the mainline to be frozen after rc1.
> I guess branching can happen at the point there is either rc2 or
> the 4.3.0 release.
I'm following this discussion closely, of c
On Mon, Oct 29, 2007 at 22:30:20 +0100, Eric Botcazou wrote:
> See gcc/gthr-posix.h for a proper use of "volatile" for a shared access.
It was already shown that you can't use volatile in general case,
because you can't pass such data to any function. See the mail of
Bart Van Assche.
The use doe
> The use doesn't become proper simply because it appears in the code,
> even if in the code of GCC. volatile might be used there for
> completely different reasons.
No, I put it there for this purpose.
--
Eric Botcazou
> I have applied the "final" patch, if you want to re-test.
Slightly better, but not much (7 min for a full-checking bootstrap).
--
Eric Botcazou
> Note also that excessive inlining often is a loss due to
> increase in icache pressure. In Ada it is the style to
> carefully mark inlinable routines with pragma Inline, and
> we often find in Ada that use of -O3, which activates
> automatic inlining, going beyond what the programmer has
> asked
I accidentally removed the essential line, it should be:
On Tue, Oct 30, 2007 at 10:44:52 +0300, Tomash Brechko wrote:
> static volatile int __gthread_active = -1;
>
> ...
int __gthread_active_latest_value = __gthread_active;
> /* This test is not protected to avoid taking a lock
On Tue, Oct 30, 2007 at 08:56:08 +0100, Eric Botcazou wrote:
> > The use doesn't become proper simply because it appears in the code,
> > even if in the code of GCC. volatile might be used there for
> > completely different reasons.
>
> No, I put it there for this purpose.
Then you could remove
83 matches
Mail list logo
