<div dir="ltr"><div dir="ltr">On Mon, Nov 30, 2020 at 10:28 PM John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px">
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">That’s true but not really what I mean.  In practice, it is hard to specify<br>
the rules that will make your analysis and transformations valid on the<br>
LLVM IR level, and you will find yourself reasoning a lot about what a<br>
reasonable frontend would emit for particular patterns of code.  When you<br>
find yourself doing that kind of reasoning, you are almost certainly in a<br>
bad place where you’re not going to meet your goals, and you need to be<br>
doing the optimization at a level that still preserves the semantic<br>
structure you’re trying to reason about.  Unfortunately this is a problem<br>
in Clang, because there’s no IR designed for optimization prior to LLVM<br>
IRGen.</p></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I can always revisit this intrinsic idea at a later point.</div><div><br></div><div>Again, thanks for your thoughtful reply,</div><div>Ola.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
</div>
</div>
</div>

</blockquote></div></div>