Ola Fosheim Grøstad via llvm-dev
2020-Dec-05 19:32 UTC
[llvm-dev] Should I add intrinsics to write my own automatic reference counting passes?
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>