Not logged in
Log in now
Create an account
Subscribe to LWN
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
LWN.net Weekly Edition for June 6, 2013
Threads are supposed to share all memory, aren't they?
>You've just killed all compiler optimization.
Only the unsafe ones. There are plenty of opportunities for optimization, but I don't think this is an example of one.
Posted Aug 13, 2012 16:41 UTC (Mon) by daglwn (subscriber, #65432)
It depends on the threading model and since the standard doesn't specify one, the compiler cannot know in the general case.
Now, gcc has for example the -pthreads switch that tells it something about what to expect so that can help. But the kernel build system almost certainly doesn't use that.
> There are plenty of opportunities for optimization, but I don't think
> this is an example of one.
When one restricts what is know about memory accesses, the compiler kills a *lot* of compiler transformation. Much much more than one would think. Spill code gets a lot more inefficient, for example, which you wouldn't expect to happen since spills are entirely local. But it does because the compiler cannot do certain peeps that can help reduce the amount of spill code.
The "big" transformations like loop restructuring, vectorization and the like are almost impossible if the behavior of memory can't be determined. These are no more "unsafe" than any other transformation. The compiler won't do them if it doesn't know it's safe according to the standard.
Posted Aug 13, 2012 16:58 UTC (Mon) by jwakely (subscriber, #60262)
Except that for many platforms it's equivalent to '-D_REENTRANT -lpthread' and so only affects the preprocessor and linker, which doesn't tell the compiler anything.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds