From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Quinlan Subject: Re: [9fans] (no subject) To: 9fans@cse.psu.edu Message-id: <3C831986.12135F97@research.bell-labs.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: Date: Mon, 4 Mar 2002 01:51:50 -0500 Topicbox-Message-UUID: 5e376bea-eaca-11e9-9e20-41e7f4b1d025 I suspect most compilers will not registerize a global over a function call. The main problem with registerizing globals is that it might be aliased by a function paramter. This has nothing to do with the issue of threads. In plan9 the following code produces different output depending on whether optimisation is on or off. #include #include int x = 1; void foo(int *p) { int i; for(i=0; i<10; i++) { *p = i; x += x+i; } } void main(void) { foo(&x); print("x = %d\n", x); } one could claim this is a bug; Ken said he never gets caught by real code - at least code we write. Many of the optimising C compiliers I have used will assume in code such as #include "stdio.h" int foo(int *p, short *s) { int i, j; j = 0; for(i=0; i<100; i++) { j += *p + *s; *p = j; } return j; } that *p and *s do not alias each other and thus the reference to *s in the loop can be moved out of the loop and placed in a register. Since I am not a language lawyer, I don't know what the C standard says about this, but this type of optimisation does break a lot of poorly written code. Since gcc is C by definition, I had a look what it does. Naturally, they have this optimisation, and an option to turn it on or off -fstrict-aliasing -- turns it on -fno-strict-aliasing -- turns it off Naturally, -O2 may enable this optimisation depending on the version of the compiler that is used. From what I can gather from a quick search of the internet, this optimisation got turned on by defualt with -O2, tons of code broke including the linux kernel. Next release turns it off, then all the broken programs add -fno-strict-aliasing to their Makefiles, then after sufficent time, the option is turned back on by default... From what I gather, gcc 3.0 and up have this option on by default with -O2, though I do not have access to a system that runs this compiler and thus have not actually checked this is the case. This is the type of problem that forces the linux world to exactly match the version of the compiler with the version of the code they are compiling... sape@plan9.bell-labs.com wrote: > > > On registerizing globals, it seems to be that it's > > entirely safe to registerize as long as control flow > > doesn't leave your function. I.e., don't expect > > registerized globals not to mutate across function > > calls. Threaded programmers know what they're getting > > themselves into, and ought to be using locks or > > condition variables. > > Locks and condition variables aren't good enough, unless there > is a mechanism in the optimizing compiler to link locks to > registerized globals (flush before unlock, reread after lock), > or a mechanism to tell the compiler to flush before a context > switch and reload after one. > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Subject: [9fans] (no subject) > Date: Wed, 27 Feb 2002 17:47:15 -0500 > From: presotto@plan9.bell-labs.com > Reply-To: 9fans@cse.psu.edu > To: 9fans@cse.psu.edu > > This is what I got out of Cliff Young: > > Do you mean about the general 9fans topic of > whether optimizations are dangerous, or about > the specific issue of when you can registerize > a global? > > On the former, one person made the rarely-made point > that many people write programs that depend on undefined > behavior in the C standard, then gripe when their bugs > that are masked with -O0 are exposed with -O2. I think > this point isn't made often enough. > > On the other hand, I'm entirely willing to admit that > buggy optimizations passes are the reason why people > turn optimizations off. It's hard to write optimizations > that are as reliable as, say, hardware. Part of this is > that the verification technology is way better on the > hardware side, and another part is that writing a > good optimizing compiler is a never-ending time sink, > and it's hard to get users to send you examples that > exhibit bugs, and then even harder to track them down. > And this in a program that isn't multithreaded. > > On registerizing globals, it seems to be that it's > entirely safe to registerize as long as control flow > doesn't leave your function. I.e., don't expect > registerized globals not to mutate across function > calls. Threaded programmers know what they're getting > themselves into, and ought to be using locks or > condition variables.