<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 14 Nov 2019, at 13:37, Michael Spencer via llvm-dev wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">On Thu, Nov 14, 2019 at 9:59 AM Reid Kleckner via llvm-dev <<br>
llvm-dev@lists.llvm.org> wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">I think the idea of more expanded frontend support library makes sense.<br>
The main use case that I've heard for such a library is to help frontends<br>
generate LLVM IR that interfaces with the local native C ABI.<br>
</p>
</blockquote><p dir="auto">I agree it would be good to have a library for shared frontend code, and<br>
the C ABI library is what I jumped to immediately too. I'm fine with it<br>
being part of LLVM proper, but I do wonder if it would be better as a<br>
separate top level project. Now that we have the monorepo it's<br>
significantly less of a barrier for Clang to grow a dependency on another<br>
LLVM subproject. In fact I can't really think of any reason it's not free,<br>
pretty sure it requires zero extra steps while setting up a build.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">There is no reasonable way to express this at the LLVM level.<br>
The C ABI relies on C type-system concepts, and it doesn’t make any<br>
sense to slowly clone the entire C type system into some LLVM-level<br>
library when that’s already the purpose of the Clang AST. So this<br>
should really be a Clang-level library.</p>
<p dir="auto">Now, that Clang-level library could very reasonably be built on top<br>
of an LLVM-level library. I think it would really nice to have an<br>
LLVM-level library that provides basic abstractions analogous to<br>
what Clang has as CodeGenFunction/CodeGenModule and Swift has as<br>
IRGenFunction/IRGenModule. At the LLVM level, that function-builder<br>
abstraction would basically be an IRBuilder plus some basic support<br>
for control flow, which IRBuilder has never done well. The Clang-level<br>
abstractions would then have functions for things like:</p>
<ul>
<li>lowering a Clang type into an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">llvm::Type*</code></li>
<li>emitting a function prototype as an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">llvm::Function*</code></li>
<li>emitting calls given an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">llvm::FunctionBuilder</code></li>
<li>accessing a field of a Clang struct type</li>
<li>etc.</li>
</ul>
<p dir="auto">I’ve thought about trying to build some of these abstractions on<br>
top of IRBuilder, but it really isn’t good enough because you need some<br>
more holistic things when you’re building a function from scratch.<br>
For example, it’s really useful to maintain a separate insertion point<br>
in the entry block so that allocas show up in the same order you created<br>
them instead of reverse order. And it’s good to have well-thought-out<br>
conventions for how you deal with reaching the end of a block and so on.</p>
<p dir="auto">Anyway, if we had that Clang-level library, t would be fairly<br>
straightforward for someone interoperating with the C ABI to just<br>
construct the appropriate Clang types and call those APIs.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>