<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 30, 2015 at 6:21 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><span style="color:rgb(34,34,34)">We exploit undefined behavior because it helps to optimize real programs and shrink the size of generated code.</span></div></div></blockquote><div><br></div><div>That is the reason compilers exploit undefined behaviour even when they are generating code for a vanilla architecture with a flat address space, yes. However, I will suggest:</div><div><br></div><div>1. The performance gain from this on real programs is small. I will suggest that the total performance gain from optimisations that rely on exploiting undefined behaviour - let's call them monkey's paw optimisations for short - is practically never more than a few percent, and often less than one percent.</div><div><br></div><div>2. For most programs, having the program work is worth far more than having it run a few percent faster.</div><div><br></div><div>3. If you look at the survey answers, it's clear that most real programs, whether deliberately or accidentally, invoke undefined behaviour at some point. You could say this is the programmer's fault, but in practice, miscompiling a program typically punishes people other than the programmer who wrote the code in question (and who may at this stage be long gone). Furthermore, so little behaviour is actually defined by the letter of the C and C++ standards, that the probability of even a team of highly skilled and conscientious programmers writing a million line program without ever invoking undefined behaviour is for all practical purposes zero.</div><div><br></div><div>I am frankly of the opinion that monkey's paw optimisations cause so much trouble and are so difficult (for all practical purposes impossible) to avoid tripping over, that it would be better to remove them entirely, but given that compiler maintainers are clearly unwilling to do that, I propose the following compromise:</div><div><br></div><div>Group all monkey's paw optimisations together, and enable them only if an extra compiler flag is supplied. Or failing that, at least have a compiler flag that will disable all of them (while leaving all the safe optimisations enabled). </div></div></div></div>