Re: Summary of "Languages that give 'hints' to the compiler"

Joe Hummel <jhummel@cy4.ICS.UCI.EDU> writes:
[...]
|> If the programmer explicitly applies an optimization, and does it
|> incorrectly, when it comes time for debugging they at least have the
|> advantages that: (1) they can see the source code as it will run, and
|> (2) they have written the source code and so hopefully have a good
|> understanding of what they have done. If the compiler applies the
|> optimization due to an incorrect assertion, the programmer will have
|> a harder time debugging since (1) they don't generally get to see the
|> resulting source code, and (2) they may not understand the resulting
|> code even if they could see it (since the compiler did the optimization).


But if the programmer applies an optimization that is correct at the time,
and changes that invalidates the basis for the optimization is made later,
then (2) does not necessarily apply. While (1) remain valid, it can be
very hard to find out which assumptions are used where. It may be much
easier to see that an *explicit* assertion no longer holds.


|> Plus, the effect of an assertion may be long-lasting, and thus catch the
|> programmer unaware downstream, making it even more difficult to figure out
|> which assertion is invalid.


Yes, but the corresponding hand optimized code may very well be completly
impossible to figure out by then. If you have non-working code you do not
understand, then you have to rewrite it or figure it out -- with explicit
assertions you can always fix the problem by removing the asertions and
get working, if slow code.


|> On the other hand, there are ways to debug one's assertions, [...] Are they
|> better solutions, e.g. run-time checking?


Assuming a special debug mode where assertions are *not* used to optimize
the code, but rather extra code is generated to check assertions, many
assertions could be runtime checked. In some cases directly, as for
typical simple pre- and postconditions, in other cases you could make
partial indirect checks. For example, for "pure function" (returning the
same output for the same input, no *visible* side effects) you could
probably not restrict the side effects (assuming you will allow some
side-effects, like software caching) but you could store some of the
earlier results and check that the newly computed result agrees with those.


Anders Andersson
andand@sics.se
--

Return to the comp.compilers page.
Search the comp.compilers archives again.