Boost logo

Boost :

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-11-18 10:32:47

On Nov 18, 2004, at 10:08 AM, Stefan Seefeld wrote:

>> From: Doug Gregor [mailto:dgregor_at_[hidden]]
>> Since I've been researching in this area for several years...
>> Dave is correct: no compiler out there is going to optimize this,
>> because the side effects are killer. It is possible to analyze that
>> behavior and perform the optimization Thorsten is describing, but
>> (1) There are better ways than looking at it from the memory
>> subsystem/pointer magic angle
>> (2) This is very much an open research area; don't
>> expect this from a
>> research compiler for at least 2 years.
>> (3) This is very much an open research area; don't
>> expect this from a
>> commercial compiler for at least 10 years.
>> Copy elision and the RVO are all we have. We can't rely on anything
>> more than that.
> out of curiosity: what about the LD_PRELOAD trick that's used on
> ELF systems to replace symbols at startup ? It's notably used by
> some tools to swap in special versions of operator new/delete to
> analyze memory management without the need to recompile anything.

The problem goes well beyond replacing symbols... we'd need to so some
nontrivial analysis to determine that the operation had no side
effects, ignore side effects in the memory subsystem, and then rewrite
substantial pieces of code.

> Is there any way for a compiler to know that some calls can be fully
> evaluated at compile-time ?

Sure. It's generally called "partial evaluation", where part of the
program is evaluated at compile time, and that may include function


Boost list run by bdawes at, gregod at, cpdaniel at, john at