[cfe-dev] Smart Pointer Lifetime Optimizations

[Arthur O'Dwyer via cfe-dev]

On Wed, Jun 10, 2020 at 11:41 AM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:

> On 6/10/20 10:31 AM, Arthur O'Dwyer wrote:
> > I mentioned to Zoe offline that I'd like to see Clang add an opt-in
> > non-conforming optimization mode, on the lines of `-ffast-math`, which
> > would *assume* things like "things passed by const reference don't
> change"
> > and "things passed by reference don't escape," and then measure to what
> > degree codegen is improved on real codebases by that non-conforming
> > optimization mode.
>
> Interesting, especially to determine lost performance potential [0].
> [0] https://link.springer.com/chapter/10.1007/978-3-030-20656-7_13
>

Exactly! :)  And I see you're the first author of that paper!
Fulltext PDF: "Performance Exploration Through Optimistic Static Program
Annotations" (Doerfert, Homerding, Finkel; 2019)
<https://github.com/jdoerfert/PETOSPA/blob/master/ISC19.pdf>
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.)

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

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.

Thoughts? Is there any chance you *could *run a test like that in the next
month or two?
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/4c9b8ec4/attachment.html>