[llvm-dev] [RFC] Create llvm/lib/Frontend
John McCall via llvm-dev
llvm-dev at lists.llvm.org
Fri Nov 15 16:25:09 PST 2019
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev