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

Joe Hummel <jhummel@cy4.ICS.UCI.EDU> first wrote:
> The big gotcha of course: what if the programmer supplies info, and he/she
>is wrong?


Wolfgang Grieskamp <wg@cs.tu-berlin.de> then wrote:
>I do not see much differences to that the programmer assumes some
>properties of her code for the validity of handcrafted
>optimizations. Its even better, since the assumptions are stated
>explicitely.


(Actually I agree with you, but playing devil's advocate...)


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


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.


On the other hand, there are ways to debug one's assertions, e.g. by
selectively disabling assertions until the code runs correctly. But is
this a viable solution? Are they better solutions, e.g. run-time
checking?


I'm curious to hear what others think...


    - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: jhummel@ics.uci.edu
--

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