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.
