<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Jun 10, 2020 at 11:41 AM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On 6/10/20 10:31 AM, Arthur O'Dwyer wrote:<br>> I mentioned to Zoe offline that I'd like to see Clang add an opt-in<br>
> non-conforming optimization mode, on the lines of `-ffast-math`, which<br>
> would *assume* things like "things passed by const reference don't change"<br>
> and "things passed by reference don't escape," and then measure to what<br>
> degree codegen is improved on real codebases by that non-conforming<br>
> optimization mode.<br>
<br>
Interesting, especially to determine lost performance potential [0].<br><span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">[0] </span><a href="https://link.springer.com/chapter/10.1007/978-3-030-20656-7_13" rel="noreferrer" target="_blank">https://link.springer.com/chapter/10.1007/978-3-030-20656-7_13</a><br></blockquote><div><br></div><div>Exactly! :)  And I see you're the first author of that paper!</div><div>Fulltext PDF: <a href="https://github.com/jdoerfert/PETOSPA/blob/master/ISC19.pdf">"Performance Exploration Through Optimistic Static Program Annotations" (Doerfert, Homerding, Finkel; 2019)</a></div><div>If I understand correctly, what you did there was have the compiler add annotations to every possible site, and then iteratively use an "acceptance test" to find out which annotations broke the program and must be rolled back, until you arrived at a local minimum. (Similar to what C-Reduce does.)</div><div><br></div><div>My idea of a "-ffast-math–style" opt-in mode couldn't depend on the existence of an "acceptance test" for the program it was compiling. It would blindly use heuristics invented by the Clang developer, such as "things marked const should always be annotated readonly" and "parameters of reference type should always be annotated noescape."</div><div><br></div><div>If your PETOSPA framework hasn't yet bit-rotted, <b><i>you could use PETOSPA to sanity-check my heuristics!</i></b> Suppose you did a special run of your compiler, applying just the readonly and noescape annotations, in exactly the cases outlined in my previous paragraph. And then you run your "acceptance tests" on the resulting binaries. My hypothesis is that the acceptance tests should all pass. That is: applying these heuristics should not break any of your programs.  If applying one of these heuristics does break one of your programs, I would be very interested to learn why.</div><div><br></div><div>Thoughts? Is there any chance you <i><b>could </b></i>run a test like that in the next month or two?</div><div>–Arthur</div></div></div></div></div>