Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,124 of 33,346    |
|    Francis Glassborow to rossmpublic@gmail.com    |
|    Re: Why is there no input value optimiza    |
|    12 Apr 12 12:51:20    |
      0f9cf28a       From: francis.glassborow@btinternet.com              On 12/04/2012 11:05, rossmpublic@gmail.com wrote:       > On Tuesday, April 10, 2012 11:14:08 AM UTC-7, Alf P. Steinbach wrote:       >> The compiler is able to do it within the current language, but it's       >> constrained by       >>       >> * the problem of aliasing, i.e. correctness violation, and       >>       >> * depending on the solution, a combinatorial explosion, and that       >>       >> * depending on the solution, the linker must support the scheme.       >       > Thanks for the analysis Alf. On the surface it looks like the       > separate compilation model sinks attempts to provide input value       > optimization as Dave Abrahams mentioned. But perhaps a really robust       > compiler/linker would be able to do it?       >       > Here's what I've been thinking. Let's start with something simple:       >       > - Only apply optimization to classes with non trivial constructors       > or POD classes of a certain size. To avoid pessimizations.       >       > - Restrict candidates for this optimization to parameters       > that are only copied inside the function.       >       > - If the parameter is passed by reference to any function (including       > constructors) it cannot be optimized. Perhaps we may want to       > allow const references for an aggressive optimization strategy but       > this would not be strictly correct/conforming.       >       > - The goal is to guarantee that when the function exits that the       > parameter will not be modified if it is passed by reference.       > Therefore we can create a single optimized version of the function       > call and avoid the combinatorial explosion. Alf?       >              Rgat last is not sufficient in multi-threaded/concurrent code. You       must also guarantee that the bject passed be reference is not modified       elsewhere during the execution of the function. I think that is a       more demanding requirement these days and would effectively require       the implementation to do much more analysis before optimising.              Note that an implementation can already do what you ask under the 'as       if' rule as long as it can demonstrate that the choice cannot be       detected by the program behaviour (other than efficiency)              Francis                     --        [ See http://www.gotw.ca/resources/clcm.htm for info about ]        [ comp.lang.c++.moderated. First time posters: Do this! ]              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca