[cfe-dev] Smart Pointer Lifetime Optimizations

[Johannes Doerfert via cfe-dev]

On 6/10/20 12:06 PM, Arthur O'Dwyer wrote:
> 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).

Agreed :)


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

Yes, it's implemented on IR, there is no(t much) difference.



> (2) Do you include the implicit `this` parameter?

Yes, it's implemented on IR. (Though the benchmarks were not C++ heavy, 
I think.)


> (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.
>
It is possible, yes. Doubtful from what I remember, though I had to 
check the data to make sure.


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

I am not even sure we'd break many tests. I am not aware of tests that

ensure either (1) const_cast + modify work properly, or, (2) let the pointer

escape and trigger some modification (store/free) to be moved prior to the

"hidden" read via the escaped pointer. That said, there are certainly 
situations

of (1) and (2) in the wild. I would add the annotation, run it on 
llvm-test-suite,

spec, ... and see what falls out. If there is no/little compile/runtime 
improvement,

less incentive to go forth with this. Otherwise, we can take a closer 
look at the

failure rate and determine if a user flag makes sense.


> 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!

Self hosting is certainly also a nice benchmark here.



>
> –Arthur
>