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

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.

- Michael Spencer

>
> However, I wonder if OpenMP should be its own (sub?) library, since I
> can't imagine that Swift, Rust, or Julia will need this OpenMP logic.
It
> seems specific to C and Fortran. I was thinking something like
> llvm/lib/Frontend/OpenMP.
>
> On Tue, Nov 12, 2019 at 9:20 PM Doerfert, Johannes via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I was hoping to introduce a new top level library in llvm/lib/Frontend
>> for code that is (mainly) used by LLVM frontends but not by one
>> exclusively. At first, I would place the OpenMP-IR-Builder [1] (and
>> related
>> code [0]) there. This Builder translates "OpenMP directives"
to LLVM-IR
>> and is supposed to be reused in Flang.
>>
>> First, I tried to place the OpenMP-IR-Builder into llvm/IR, right next
>> to the llvm::IRBuilder, but it would soon introduce a dependence on
>> other libraries (first TransformUtils) [2].
>>
>> There are more things (especially parts of Clang) that could arguably
be
>> shared across frontends and therefore be moved into a such a dedicated
>> location. If it turns out this is a controversial RFC, we will provide
>> examples and reasons.
>>
>> I hope this is fairly straightforward as this does not introduce any
>> drawbacks (I know of).
>>
>> Please let me know if you have an opinion on this.
>>
>> Thanks,
>>   Johannes
>>
>>
>>
>>
>> [0] https://reviews.llvm.org/D69853
>> [1] https://reviews.llvm.org/D69785
>> [2] https://reviews.llvm.org/D70109
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191114/6c8c3e59/attachment.html>

On 11/14, Michael Spencer 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.
Would it be OK to start with a library in LLVM core and determine then
if we need a project? I ask because of time reasons not because I oppose
the idea in any way. New subprojects have way more implications and
requirements than a new library in core would have.
> > However, I wonder if OpenMP should be its own (sub?) library, since I
> > can't imagine that Swift, Rust, or Julia will need this OpenMP
logic. It
> > seems specific to C and Fortran. I was thinking something like
> > llvm/lib/Frontend/OpenMP.
I could easily do that.

(FWIW, I like the subproject idea even when I was actually hoping that
 non-OpenMP languages could eventually piggyback on the OpenMP runtime
 etc. at some point, but that is nothing I actively work on right now.)

> > On Tue, Nov 12, 2019 at 9:20 PM Doerfert, Johannes via llvm-dev <
> > llvm-dev at lists.llvm.org> wrote:
> >
> >> I was hoping to introduce a new top level library in
llvm/lib/Frontend
> >> for code that is (mainly) used by LLVM frontends but not by one
> >> exclusively. At first, I would place the OpenMP-IR-Builder [1]
(and
> >> related
> >> code [0]) there. This Builder translates "OpenMP
directives" to LLVM-IR
> >> and is supposed to be reused in Flang.
> >>
> >> First, I tried to place the OpenMP-IR-Builder into llvm/IR, right
next
> >> to the llvm::IRBuilder, but it would soon introduce a dependence
on
> >> other libraries (first TransformUtils) [2].
> >>
> >> There are more things (especially parts of Clang) that could
arguably be
> >> shared across frontends and therefore be moved into a such a
dedicated
> >> location. If it turns out this is a controversial RFC, we will
provide
> >> examples and reasons.
> >>
> >> I hope this is fairly straightforward as this does not introduce
any
> >> drawbacks (I know of).
> >>
> >> Please let me know if you have an opinion on this.
> >>
> >> Thanks,
> >>   Johannes
> >>
> >>
> >>
> >>
> >> [0] https://reviews.llvm.org/D69853
> >> [1] https://reviews.llvm.org/D69785
> >> [2] https://reviews.llvm.org/D70109
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191114/ced94223/attachment.sig>

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>

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