Optimization of conditional access to globals: thread-unsafe?

Hello, I have a question regarding the thread-safeness of a particular GCC optimization. I'm sorry if this was already discussed on the list, if so please provide me with the reference to the previous discussion. Consider this piece of code: extern int v; void f(int set_v) {

Re: Optimization of conditional access to globals: thread-unsafe?

Dave Korn wrote: On 27 October 2007 18:27, Darryl Miles wrote: The "unintended write-access" optimization is a massive headache for developers of multi-threaded code. But it's a boon for the autovectoriser, because it means it can transform code with a branch into straight-line code. Then

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/27/07, Florian Weimer <[EMAIL PROTECTED]> wrote: > > Anyway, not reordering across function calls is not sufficient to get > sane threading semantics (IIRC, this is also explained in detail in Hans > Boehm's paper). Hello Florian, In Hans Boehm's paper the following issues are identified: 1

Re: Optimization of conditional access to globals: thread-unsafe?

Bart Van Assche wrote: My opinion is that, given the importance of multithreading, it should be documented in the gcc manual which optimizations can cause trouble in multithreaded software (such as (3) and (4)). It should also be documented which compiler flags must be used to disable optimizati

Re: Optimization of conditional access to globals: thread-unsafe?

Bart Van Assche writes: > We need a solution today for the combination of C/C++ and POSIX > threads, we can't wait for the respective language standardization > committees to come up with a solution. And, in the proposed memory model, I believe we have one. If there is some reason you believe

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 09:47:36 -0400, Robert Dewar wrote: > Bart Van Assche wrote: > > >Requiring that all thread-shared variables should be declared > >volatile is completely unacceptable. > > Why is this unacceptable .. seems much better to me than writing > undefined stuff. There's a parall

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 13:32, Bart Van Assche wrote: > Requiring that all > thread-shared variables should be declared volatile is completely > unacceptable. Any variable that may be altered by an external unpredictable asynchronous 'force majeure' must be declared volatile or the behaviour is un

Re: Optimization of conditional access to globals: thread-unsafe?

Hi, On Fri, 26 Oct 2007, Tomash Brechko wrote: > On Fri, Oct 26, 2007 at 21:45:03 +0400, Tomash Brechko wrote: > > Note that it doesn't cancel cmoves, as those are loads, not stores. > > I just checked with x86 instruction reference, CMOVcc is reg->reg or > mem->reg, never reg->mem. You know Go

Re: Optimization of conditional access to globals: thread-unsafe?

Hi, On Fri, 26 Oct 2007, David Miller wrote: > Also, it bears repeating that whatever performance argument you make for > or against this issue matters little if it breaks lots of existing and > working code. It matters insofar as that existing and working code is broken in a strict sense. A

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson 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'. How does it say this, in some semantically precise way, or with hand waving as in this sentence. This me

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > On 28 October 2007 13:32, Bart Van Assche wrote: > > > Requiring that all > > thread-shared variables should be declared volatile is completely > > unacceptable. > > Any variable that may be altered by an external unpredictable asyn

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > > On 28 October 2007 13:32, Bart Van Assche wrote: > > > > > Requiring that all > > > thread-shared variables should be declared volatile is completely > > > unacceptable. > > > >

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: > Erik Trulsson 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'. > > How does it say this, in s

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson <[EMAIL PROTECTED]> writes: > I don't have access to the POSIX standard itself See . Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerpr

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 06:29:44PM +0100, Richard Guenther wrote: > On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > > On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > > > On 28 October 2007 13:32, Bart Van Assche wrote: > > > > > > > Requiring that all > > > > thread-shared var

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 17:51:57 +0100, Michael Matz wrote: > I was merely showing that this transformation _does_ matter in some cases > to refute opposite claims which seemed to be expressed too airy in this > thread. You got my intent all wrong. Performance matters for both sides. And curre

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 17:39, Erik Trulsson wrote: > On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: >> Erik Trulsson 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

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 21:03:09 +0300, Tomash Brechko wrote: > What I was trying to say, is that it would be nice to have > -fno-thread-unsafe-optimization option. Rather clear -fno-speculative-store, in the light of mprotect() and non-writable memory. -- Tomash Brechko

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 06:06:17PM -, Dave Korn wrote: > On 28 October 2007 17:39, Erik Trulsson wrote: > > > On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: > >> Erik Trulsson wrote: > >> > >>> Unfortunately it seems that the POSIX standard for threads say that as > >>> long as

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:29 +0100, Richard Guenther wrote: > 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'. >

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 19:36 +0100, Erik Trulsson wrote: > > Having just been pointed to that copy of the SUS, I must agree. I can't > find anything in there saying anything at all about what is required to > safely share data between threads. If that is really so it seems 'pthreads' > are even

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, Robert Dewar <[EMAIL PROTECTED]> wrote: > Bart Van Assche wrote: > > > My opinion is that, given the importance of multithreading, it should > > be documented in the gcc manual which optimizations can cause trouble > > in multithreaded software (such as (3) and (4)). It should also be

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, skaller <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-10-28 at 18:29 +0100, Richard Guenther wrote: > > 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

Re: Optimization of conditional access to globals: thread-unsafe?

From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > I mean who am I to demand that people write correct code, > I must be insane. Correctness is defined by pervasive common usage as much as it is by paper standards.

Re: Optimization of conditional access to globals: thread-unsafe?

From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > > You mean like POSIX doesn't count very much for the kernel behaviour? > Nice scarecrow. Linux has and will break POSIX where POSIX asks unreasonable and stupid things. And in particular we will not follow P

RE: Optimization of conditional access to globals: thread-unsafe?

On 29 October 2007 01:01, David Miller wrote: > From: Michael Matz <[EMAIL PROTECTED]> > Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > >> >> You mean like POSIX doesn't count very much for the kernel behaviour? >> > > Nice scarecrow. > > Linux has and will break POSIX where POSIX asks unreaso

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 18:03, Tomash Brechko wrote: > You got my intent all wrong. Performance matters for both sides. And > currently the only option for multithreaded programs is to use > volatile, which _greatly_ hurts performance. > > What I was trying to say, is that it would be nice to have >

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 01:05:06 - > "My way is right and everyone else's is wrong". I didn't say that. I said that what users do on a broad scale is an important consideration that often trumps paper standards. And yes, users as well as the implemento

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 01:16:07 - > Thing is, if you disable all optimisations that are potentially > unsafe in the presence of threads, won't you just get the same > effect as if you had used volatile anyway, only on every single > variable in the progr

Re: Optimization of conditional access to globals: thread-unsafe?

David Miller wrote: From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) I mean who am I to demand that people write correct code, I must be insane. Correctness is defined by pervasive common usage as much as it is by paper standards. Reading this threa

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 22:41 +0100, Richard Guenther wrote: > > OK .. hmm .. well this is the idea, but a more formal proof > > would be cool. > > Doesn't work: Of course it works. > you cannot do such analysis without seeing the whole program. There's no need. A mutex is assumed at each funct

RE: Optimization of conditional access to globals: thread-unsafe?

On 29 October 2007 01:38, David Miller wrote: > From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Mon, 29 Oct 2007 01:16:07 - > >> Thing is, if you disable all optimisations that are potentially >> unsafe in the presence of threads, won't you just get the same >> effect as if you had used volat

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 02:39:15 - > BTW, you and Tomash should get your stories in synch. He says > speculative loads are ok, just no stores, and wants a kind of > half-volatile flag that would only suppress stores. I think you're > already looking one

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 02:39:15 - > On 29 October 2007 01:38, David Miller wrote: > > > Even basic correct single-threaded UNIX programs are broken by these > > speculative stores. If I use a conditional test to protect access to > > memory mmap()'d with

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 21:43 +0100, Bart Van Assche wrote: > On 10/28/07, Robert Dewar <[EMAIL PROTECTED]> wrote: > > Bart Van Assche wrote: > > > > > My opinion is that, given the importance of multithreading, it should > > > be documented in the gcc manual which optimizations can cause trouble >

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:34 -0700, David Miller wrote: > More importantly, you cannot break things on people out of mere > convenience. If you want a case of this .. its the ill-considered strict aliasing rules in C. WG14 seems to think C had a strong enough type system to make this rule, but it

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:37 -0700, David Miller wrote: > From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Mon, 29 Oct 2007 01:16:07 - > The compiler simply cannot speculatively load or store to variables > with global visibility. I think it can. > Suggesting volatile is totally impractical and

Re: Optimization of conditional access to globals: thread-unsafe?

From: skaller <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 14:21:10 +1100 > > On Sun, 2007-10-28 at 18:37 -0700, David Miller wrote: > > Even basic correct single-threaded UNIX programs are broken by these > > speculative stores. If I use a conditional test to protect access to > > memory mmap()'d

Re: Optimization of conditional access to globals: thread-unsafe?

Dave Korn wrote: On 29 October 2007 01:38, David Miller wrote: You'll be back. Next week, you'll discover a corner case where caching a shared variable in a register can be a bad thing when one thread uses locks and the other doesn't, and you'll be back to demand that optimisation is remo

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 20:32 -0700, David Miller wrote: > From: skaller <[EMAIL PROTECTED]> > > That is the programmers fault, they should have accessed the > > variable using a const. Failing to do so gives the compiler > > permission to write speculatively. > > I do not agree with you. Yeah,

Re: Optimization of conditional access to globals: thread-unsafe?

David Miller wrote: The compiler simply cannot speculatively load or store to variables with global visibility. s/with global visibility/with visibility outside the scope of the functional unit the compiler is able to see at compile time/ Which basically means the compiler is king for doing

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson wrote: On Sun, Oct 28, 2007 at 06:06:17PM -, Dave Korn wrote: As far as I know, there is no separate 'pthreads' spec apart from what is defined in the Threads section (2.9) of the SUS (http://tinyurl.com/2wdq2u) and what it says about the various pthread_ functions in the sy

Re: Optimization of conditional access to globals: thread-unsafe?

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. int *counter; void foo(int counter_is_valid) { if (counter_is_va

Re: Optimization of conditional access to globals: thread-unsafe?

On Mon, Oct 29, 2007 at 02:39:15 -, Dave Korn wrote: > BTW, you and Tomash should get your stories in synch. He says speculative > loads are ok, just no stores, and wants a kind of half-volatile flag that > would only suppress stores. I think you're already looking one step further > down t

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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 >

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

> "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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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:

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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.

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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.

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

> 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

Re: Optimization of conditional access to globals: thread-unsafe?

> Frankly, you realise the consequences of volatile access, you have > this comment: > > /* Avoid reading __gthread_active twice on the main code path. */ > int __gthread_active_latest_value = __gthread_active; > > > Now, do you really believe that every multithreaded program should use > vola

  1   2   3   >