John Regehr on "Use of Assertions"
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Wed Sep 5 21:34:59 UTC 2018
On Wednesday, 5 September 2018 at 19:35:46 UTC, Meta wrote:
> I don't disagree. I think the only sane way to use asserts as
> an optimization guide is when the program will abort if the
> condition does not hold. That, to me, makes perfect sense,
> since you're basically telling the compiler "This condition
> must be true past this assertion point, because otherwise
> program execution will not continue past this point". You're
> ensuring that the condition specified in the assert is true by
> definition. Not having that hard guarantee but still using
> asserts as an optimization guide is absolutely insane, IMO.
Yes, if you have an advanced optimizer then it becomes dangerous.
Although a prover could use asserts-with-a-hint for focusing the
time spent on searching for proofs. It would be way too slow to
do that for all asserts, but I guess you could single out some of
the easier ones that are likely to impact performance. That would
be safe.
There are some cases where "assume" makes sense, of course. For
instance if you know that a byte-pointer will have a certain
alignment then you can get the code gen to generate more
efficient instructions that presume a certain alignment or if you
can tell the compiler to "assume" that a region of memory is
filled with zeros then maybe the optimizer can skip
initialization when creating objects...
And it kinda make sense to be able to autogenerate tests for such
assumptions for debugging. So it would be like an
assert-turned-into-assume, but very rarely used...
This would be more of an expert tool for library authors and
hardcore programmers than a general compiler-optimization.
More information about the Digitalmars-d
mailing list