[cfe-dev] Smart Pointer Lifetime Optimizations

[Johannes Doerfert via cfe-dev]

On 6/10/20 11:17 AM, Arthur O'Dwyer wrote:
> 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.)

Pretty much, yes. (Slides and paper attached in case that helps.)


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

Agreed. Totally. You would probably still run your tests (I mean the

user would). It is just a single manually triggered flag instead of

an automatic exploration. Not to say this is not actually more

useful in the short term ;)


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



> Thoughts? Is there any chance you *could *run a test like that in the next
> month or two?

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?


> –Arthur
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paper.pdf
Type: application/pdf
Size: 451780 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/94fe3429/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: talk.pdf
Type: application/pdf
Size: 732279 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/94fe3429/attachment-0003.pdf>