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

[Chris Lattner via llvm-dev]

On Nov 18, 2019, at 12:17 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> On 18 Nov 2019, at 13:12, Michael Kruse wrote:
>> Am Sa., 16. Nov. 2019 um 10:56 Uhr schrieb John McCall via llvm-dev
>> <llvm-dev at lists.llvm.org>:
>>> 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.
>> 
>> The main motivation is to have ABI-emitting code (in particular for
>> OpenMP) shared between clang and flang. This structure would require
>> flang to have a dependency on clang, but conceptually they are
>> independent frontends.
>> 
>> De facto, every platform has its ABI defined in terms of C therefore
>> this would effectively required every frontend to depend on clang. I'd
>> think of the platform ABI to be independent of the parsing
>> implementation.
> 
> Fortunately, nothing about this structure would require you to link
> the Clang parser, just the AST.


While it isn’t immediately useful given how Clang works today, I feel obligated to point out that MLIR provides a new and simple way to handle these sorts of problems:

MLIR allows us to define an MLIR dialect that reflects these C-level abstractions in terms of the C level type system.  The payoff of this is that the Clang ABI lowering logic could be moved to a reusable library that is separate from the rest of the concerns of Clang’s “CodeGen” module.

MLIR allows you to directly use the existing AST clang::Type if you’d like to, but also allows defining standalone types and allows using hybrids as well.  This could be particularly useful for C type lowering since the C type system is so much simpler than the C++ type system, and not every client wants to carry around the complexity of C++: this design allows factoring that out to a separate module that one can opt into.

In any case, while such a design is possible, implementing such a thing (and refactoring Clang) would be a tremendous amount of work.  I just mention this because many folks on this thread may not be aware of the fact that we have a much larger design space to work with to solve lowering problems and the software engineering problems like code reuse than we once did.

As these things are adopted more across the ecosystem, I think it could bring a lot of increased modularity benefits to LLVM!

-Chris