[llvm-dev] [RFC] Create llvm/lib/Frontend

[John McCall via llvm-dev]

On 14 Nov 2019, at 13:37, Michael Spencer via llvm-dev wrote:

> On Thu, Nov 14, 2019 at 9:59 AM Reid Kleckner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I think the idea of more expanded frontend support library makes sense.
>> The main use case that I've heard for such a library is to help frontends
>> generate LLVM IR that interfaces with the local native C ABI.
>>
>
> I agree it would be good to have a library for shared frontend code, and
> the C ABI library is what I jumped to immediately too. I'm fine with it
> being part of LLVM proper, but I do wonder if it would be better as a
> separate top level project. Now that we have the monorepo it's
> significantly less of a barrier for Clang to grow a dependency on another
> LLVM subproject. In fact I can't really think of any reason it's not free,
> pretty sure it requires zero extra steps while setting up a build.

There is no reasonable way to express this at the LLVM level.
The C ABI relies on C type-system concepts, and it doesn’t make any
sense to slowly clone the entire C type system into some LLVM-level
library when that’s already the purpose of the Clang AST.  So this
should really be a Clang-level library.

Now, that Clang-level library could very reasonably be built on top
of an LLVM-level library.  I think it would really nice to have an
LLVM-level library that provides basic abstractions analogous to
what Clang has as CodeGenFunction/CodeGenModule and Swift has as
IRGenFunction/IRGenModule.  At the LLVM level, that function-builder
abstraction would basically be an IRBuilder plus some basic support
for control flow, which IRBuilder has never done well.  The Clang-level
abstractions would then have functions for things like:

- lowering a Clang type into an `llvm::Type*`
- emitting a function prototype as an `llvm::Function*`
- emitting calls given an `llvm::FunctionBuilder`
- accessing a field of a Clang struct type
- etc.

I’ve thought about trying to build some of these abstractions on
top of IRBuilder, but it really isn’t good enough because you need some
more holistic things when you’re building a function from scratch.
For example, it’s really useful to maintain a separate insertion point
in the entry block so that allocas show up in the same order you created
them instead of reverse order.  And it’s good to have well-thought-out
conventions for how you deal with reaching the end of a block and so on.

Anyway, if we had that Clang-level library, t would be fairly
straightforward for someone interoperating with the C ABI to just
construct the appropriate Clang types and call those APIs.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191115/d7d8d086/attachment-0001.html>