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

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.

Michael

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.

John.

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