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

[Ola Fosheim Grøstad via llvm-dev]

On Mon, Nov 30, 2020 at 10:28 PM John McCall <rjmccall at apple.com> wrote:

> That’s true but not really what I mean. In practice, it is hard to specify
> the rules that will make your analysis and transformations valid on the
> LLVM IR level, and you will find yourself reasoning a lot about what a
> reasonable frontend would emit for particular patterns of code. When you
> find yourself doing that kind of reasoning, you are almost certainly in a
> bad place where you’re not going to meet your goals, and you need to be
> doing the optimization at a level that still preserves the semantic
> structure you’re trying to reason about. Unfortunately this is a problem
> in Clang, because there’s no IR designed for optimization prior to LLVM
> IRGen.
>

Thank you for your thoughtful reply. It seems like you are speaking from
experience, so I basically conclude that I do think it is possible to do
what I intended to do, but it might limit the passes I could use and I
might find myself in a position where it would be difficult to modify my
ARC optimization code. Which is not good for a prototype-level language
anyway. From what you say it seems like I risk ending up in the IR
equivalent of reasoning about spaghetti code.

So I've decided to think more about using a more hierarchical high level IR
with clang AST nodes as children and see if I can do a "lesser" version on
the clang AST instead of the IR. This is just an idea at this point.

I am also rethinking the bruteforce approach of using LLVM and will try and
see if I can make subtree results of the high level IR cacheble somehow, so
that the results can be used between compilations. Then I guess I could
accept less performant simplification algorithms than LLVM uses on my own
IR (e.g. using Z3 in the initial version). I guess that could work out ok
in the initial version.

I can always revisit this intrinsic idea at a later point.

Again, thanks for your thoughtful reply,
Ola.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201205/75522d0c/attachment.html>