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

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
-------------- 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/20191113/0d15ef4f/attachment.sig>

"Doerfert, Johannes via llvm-dev" <llvm-dev at lists.llvm.org>
writes:
> 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.
+1

                     -David

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191114/5fc60529/attachment.html>

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 Nov 12, 2019, at 9:19 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].
Hi Johannes,

I think it is a great idea to share the OpenMP lowering code, but I’m concerned
about the name 'lib/Frontend’.  This is a very broad name and there are lots
of things that “could be useful for frontends” - and a lot of definitions of
what a “frontend" is.

WDYT about naming it something like "lib/OpenMPGen” and
generalizing/renaming it later when the scope is more clear?

-Chris
> 
> 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

On 11/18, Chris Lattner wrote:
> 
> 
> > On Nov 12, 2019, at 9:19 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].
> 
> I think it is a great idea to share the OpenMP lowering code, but I’m
> concerned about the name 'lib/Frontend’.  This is a very broad name
> and there are lots of things that “could be useful for frontends” -
> and a lot of definitions of what a “frontend" is.
Fair point. I'm open to suggestions wrt. the name. FWIW, the name was
suggested because it was not only supposed to be OpenMP stuff (soon).
> WDYT about naming it something like "lib/OpenMPGen” and
> generalizing/renaming it later when the scope is more clear?
I can do that. It was also proposed to do "lib/Frontend/OpenMP" or
something similar. Would that help or would you prefer not to have the
top level "Frontend" until we actually move other things?
> > 
> > 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
> 
-- 

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/20191119/99b6f271/attachment.sig>