[llvm-dev] Should I add intrinsics to write my own automatic reference counting passes?

[Ola Fosheim Grøstad via llvm-dev]

On Thu, Nov 19, 2020 at 1:04 AM John McCall <rjmccall at apple.com> wrote:

> The main problem for this sort of optimization is that it is difficult
> to do on an IR like LLVM’s, where the semantic relationships between
> values that exist in the program have been lowered into a sequence of
> primitive operations with no remaining structural relationship.


I understand. I think one possible advantage though would be to optimize
C++ shared_ptr as well when calling into C++ code (assuming that everything
is done with a modified version of clang++), or to provide a C library with
macros that will emit the ARC-intrinsics so that C-FFI can benefit from the
same optimizations...

Dealing with unrelated operations and retroactively attempting to infer
> relationships, as LLVM IR must, turns it into a fundamentally difficult
> analysis that often relies on semantic knowledge that isn’t expressed
> in the IR, so that you’re actually reasoning about what happens under
> a “well-behaved” frontend.
>

Yes, so basically, if one chooses to do this within the LLVM IR then it
might be difficult to share the ARC optimizations with other front ends.  I
don't  intend to give direct access to the acquire/release or the ref-count
value, so I think I can assume that the front end provides "well behaved"
IR. I only plan on providing tests for refcount==1 (I guess weak_ptr
requires tests for refcount==0 internally as well)

What I worry about with a custom IR is that generic programming can emit a
lot of conditionals that should be resolved to true/false statically before
doing the ARC passes. So if I write my own IR then I would have to
implement much of what LLVM has.

But I guess what you are saying is that it will be a significant job either
way...

(Also thanks to Florian for the OBJ-C pointers.)

Ola.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201120/9eda6bc0/attachment.html>