View mode: basic / threaded / horizontal-split · Log in · Help
January 17, 2012
Re: Could assertThrown be made safe/trusted?
On Tuesday, January 17, 2012 23:40:35 Timon Gehr wrote:
> I think he is interested in the state of implementation of specific
> compiler _optimisations_ that make use of function purity in order to
> prove their correctness. IIRC ldc has CSE for pure functions, but I
> don't know exactly.

I have no idea what currently gets optimized by the compiler with regards to 
pure except for the fact that the function must be strongly pure and that 
optimizations only ever occur in a single statement (maybe even only in a 
single expression). That's a compiler implementation issue that I don't 
generally worry about. I'd _like_ it to optimize a lot, but that could easily 
vary as the implementation changes even after the language has been fully 
implemented.

Now, if you want to test it, aside from looking at the assembly generated by 
the compiler, you could use debug{} blocks with print statements in them, 
since you can put impure code in debug{} blocks for debugging purposes. So, 
with something like

auto pureFunc(immutable Type arg)
{
debug { writefln("%s(%s): pureFunc called", __FILE__, __LINE__); }
//... code
}

it becomes easy to see how well optimized out a pure functions' calls are.

- Jonathan M Davis
January 18, 2012
Re: Could assertThrown be made safe/trusted?
H. S. Teoh:

> But since this is apparently not yet implemented, just what *is*
> implemented currently when you specify 'pure'?  Common subexpression
> factorization? Hoisting? Not (yet) memoization, apparently.

Common subexpression factorization for strongly pure functions that return integral values.

Bye,
bearophile
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home