<div dir="ltr"><div dir="ltr">On Wed, Jun 10, 2020 at 12:40 PM 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:1px solid rgb(204,204,204);padding-left:1ex">
On 6/10/20 11:17 AM, Arthur O'Dwyer wrote:<br>
> My idea of a "-ffast-math–style" opt-in mode couldn't depend on the<br>
> existence of an "acceptance test" for the program it was compiling. [...]<br>
<br>
Agreed. Totally. You would probably still run your tests (I mean the<br>
user would).</blockquote><div><br></div><div>Heh, yes. :) But if the user's tests failed, they'd have no recourse except "don't opt in anymore," similar to what would happen if their tests failed with `-ffast-math` (or with `-O3` or with `-fstrict-aliasing`, for that matter).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> If your PETOSPA framework hasn't yet bit-rotted, *you could use PETOSPA to<br>
> sanity-check my heuristics!* Suppose you did a special run of your<br>
> compiler, applying just the readonly and noescape annotations, in exactly<br>
> the cases outlined in my previous paragraph. And then you run your<br>
> "acceptance tests" on the resulting binaries. My hypothesis is that the<br>
> acceptance tests should all pass. That is: applying these heuristics should<br>
> not break any of your programs.  If applying one of these heuristics does<br>
> break one of your programs, I would be very interested to learn why.<br>
<br>
In Figure 6 we stated that only 3 pointer arguments we annotated with<br>
readnone/readonly/writeonly and none of the nocapture annotated pointers caused<br>our verification to fail. To be fair, pointer capturing is not really<br>
what you expect many functions in an HPC application to do ;)<br></blockquote><div><br></div><div>I see. The paper is unclear to me (on a quick reading) in three ways:</div><div>(1) When you say "pointer argument" do you also include "by-reference argument"?</div><div>(2) Do you include the implicit `this` parameter?</div><div>(3) IIUC, your statement in Figure 6 says that all-but-3 pointer parameters were successfully annotated with <i><b>some</b></i> annotation, but it doesn't break them down into pass-by-pointer and pass-by-const-pointer, and it doesn't break the annotations down into `readnone`/`readonly`/`writeonly`. It is theoretically possible that your all-but-3 number includes some const pointers annotated with `writeonly`(!), or that the 3 includes some const pointers. Either of those outcomes would falsify my hypothesis.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think we should "just" modify the clang codegen and run the test suite<br>
and SPEC. That way we measure the actual thing with similar work overhead.<br>
WDYT?<br></blockquote><div><br></div><div>"Just" modifying Clang would also be awesome. :)</div><div>If you modify Clang, I <i><b>expect</b></i> Clang's own test suite to fail at least twice, because you'd be deliberately introducing non-conforming compiler behavior, and the test suite should definitely treat that as a "correctness regression."</div><div>Ah: you could use this mode to <i>compile Clang itself</i> and then use "time to run Clang's test suite" as your benchmark.  If that's what you meant by "run the test suite," then I agree!<br></div><div><br></div><div>–Arthur</div></div></div>