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
