assume, assert, enforce, @safe

[Walter Bright via Digitalmars-d]

On 7/31/2014 3:21 PM, Daniel Gibson wrote:
> And I agree with your stance on those fine-grained optimization switches from
> your other post. GCC currently has 191 flags the influence optimization[1]

Just consider this from a testing standpoint. As I mentioned previously, 
optimizations interact with each other to produce emergent behavior. GCC has 191 
factorial different optimizers. Google's calculator puts 191! at infinity, which 
it might as well be.


> However, what about an extra flag for "unsafe" optimizations?

There's been quite a creep of adding more and more flags. Each one of them is, 
in a way, a failure of design, and we are all too quick to reach for that.


> I *don't*
> want it to e.g. remove writes to memory that isn't read afterwards

That's what volatileStore() is for.


> or make assumptions based on assertions (that are disabled in the current compile mode).

This is inexorably coming. If you cannot live with it, I suggest writing your 
own version of assert, using the Phobos 'enforce' implementation as a model. 
It'll do what you want.


> And maybe a warning mode that tells me about "dead"/"superfluous" code that
> would be eliminated in an optimized build so I can check if that would break
> anything for me in that respect without trying to understand the asm output
> would be helpful.

If you compile DMD with -D, and then run it with -O --c, it will present you 
with a list of all the data flow optimizations performed on the code. It's very 
useful for debugging the optimizer. Although I think you'll find it 
illuminating, you won't find it very useful - for one thing, a blizzard of info 
is generated.