[cfe-dev] Smart Pointer Lifetime Optimizations

[Arthur O'Dwyer via cfe-dev]

On Wed, Jun 10, 2020 at 12:40 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

> On 6/10/20 11:17 AM, Arthur O'Dwyer wrote:
> > 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. [...]
>
> Agreed. Totally. You would probably still run your tests (I mean the
> user would).


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

> If your PETOSPA framework hasn't yet bit-rotted, *you could use PETOSPA to
> > sanity-check my heuristics!* 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.
>
> In Figure 6 we stated that only 3 pointer arguments we annotated with
> readnone/readonly/writeonly and none of the nocapture annotated
> pointers caused
> our verification to fail. To be fair, pointer capturing is not really
> what you expect many functions in an HPC application to do ;)
>

I see. The paper is unclear to me (on a quick reading) in three ways:
(1) When you say "pointer argument" do you also include "by-reference
argument"?
(2) Do you include the implicit `this` parameter?
(3) IIUC, your statement in Figure 6 says that all-but-3 pointer parameters
were successfully annotated with *some* 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.


I think we should "just" modify the clang codegen and run the test suite
> and SPEC. That way we measure the actual thing with similar work overhead.
> WDYT?
>

"Just" modifying Clang would also be awesome. :)
If you modify Clang, I *expect* 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."
Ah: you could use this mode to *compile Clang itself* 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!

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/b011917b/attachment-0001.html>