Re: [boost] boost::shared_ptr<>::compare_and_swap()--AmIinsaneforwanting this?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Talbot, George
I also do not have a good answer to the post by Sohail Somani about what the compiler will do with this in the future.
Actually I think Visual C++ 7.1+ might already do it.
On 11/13/06, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Talbot, George
I also do not have a good answer to the post by Sohail Somani about what the compiler will do with this in the future.
Actually I think Visual C++ 7.1+ might already do it.
While it is likely that most compilers will do whole program optimizations in the future and be able to reorder across compilation units, I think that it is extremely unlikely that compilers will ever reorder instructions in pure assembly modules. First of all because to do whole program optimization they need special data produced during compilation (that assembler modules lack), and also because they would render assembler programming useless. IMHO of course. -- Giovanni P. Deretta
On 14/11/06, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
While it is likely that most compilers will do whole program optimizations in the future and be able to reorder across compilation units, I think that it is extremely unlikely that compilers will ever reorder instructions in pure assembly modules. First of all because to do whole program optimization they need special data produced during compilation (that assembler modules lack), and also because they would render assembler programming useless. IMHO of course.
If you properly wrap the assembly code in asm volatile segments the compiler should not touch them for anything. If you do not, it could change it for anything. The linker can change around anything it wants, in theory, and that's the one performing the whole-program optimizations. If they move stuff around it could get duplicated, but there should be an option telling the linker not to try that (possibly with regard to a specific function), so that current practices (specifically those relating to atomicity and protected instructions) aren't made useless. I'm not sure whether you can specify that in the code, although I expect some construction will be created to allow that specifically for supporting header-based libraries.
On 11/14/06, Peter Bindels <dascandy@gmail.com> wrote:
On 14/11/06, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
While it is likely that most compilers will do whole program optimizations in the future and be able to reorder across compilation units, I think that it is extremely unlikely that compilers will ever reorder instructions in pure assembly modules. First of all because to do whole program optimization they need special data produced during compilation (that assembler modules lack), and also because they would render assembler programming useless. IMHO of course.
If you properly wrap the assembly code in asm volatile segments the compiler should not touch them for anything. If you do not, it could change it for anything. The linker can change around anything it wants, in theory, and that's the one performing the whole-program optimizations. If they move stuff around it could get duplicated, but there should be an option telling the linker not to try that (possibly with regard to a specific function), so that current practices (specifically those relating to atomicity and protected instructions) aren't made useless. I'm not sure whether you can specify that in the code, although I expect some construction will be created to allow that specifically for supporting header-based libraries.
By external assembler modules, i meant .S files. You can't hardly wrap them using volatile asm statements as there is no concept of volatile nor asm statement there. I do not claim to know how smart linkers do WPO, but I think that they need more informations than plain machine code (note that when it is the time for the linker to do its job, object files have already been generated). This extra info is generated during compilation and probably includes the internal compiler representation of that module. As long as you feed your assembler modules to a plain assembler you should be safe. gpd
participants (3)
-
Giovanni Piero Deretta -
Peter Bindels -
Sohail Somani