assume, assert, enforce, @safe

[Daniel Gibson via Digitalmars-d]

Am 01.08.2014 03:12, schrieb Walter Bright:
> 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.

Yep, also a good point.
(Actually it's 187 -f* options, the rest is -O* which can't be combined 
of course and some of them most probably imply many of the -f* switches, 
but it'll still be an unmanageable/untestable amount of possible 
configurations)

>
>
>> 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.

Well, it would be one additional flag that would also imply -O ...
but this should probably be reevaluated when problems with 
overaggressive optimization actually occur.

>
>
>> I *don't*
>> want it to e.g. remove writes to memory that isn't read afterwards
>
> That's what volatileStore() is for.
>

Ah, sounds nice, having a standard way to do that is certainly a good 
thing! :-)
I looked at the pull request ( 
https://github.com/D-Programming-Language/druntime/pull/892 ) and I 
wonder if maybe an additional function that's equivalent to memset() and 
overwrites a whole range of memory could be added.
As memset() in C is usually much faster than iterating over the data and 
setting it to $value one by one, I guess this kind of function could 
provide a speedup here as well.

>
>> 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.

Yeah. But please update the assert() documentation so people can know 
about this.
I also wonder if this might be commonly needed and could be a good 
addition to enforce() in phobos

>
>
>> 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.
>

Sounds interesting, thanks for the hint :-)
This would probably be useful information that an IDE could (optionally) 
display alongside the actual code - I guess that could make debugging 
issues that only happen in optimized code/release mode much easier (if 
you can narrow your problem down to a few functions).

Cheers,
Daniel