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

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>

> On Nov 19, 2019, at 9:04 AM, Doerfert, Johannes <jdoerfert at
anl.gov> wrote:
> 
>>> 
>>> 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).
What are the other things?  Naming is often helped by having examples from the
broader pool that will shape this.  It will also be helpful to understand what
would be “in” vs “out” of scope for this over time.
> 
>> 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?
Sure,

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191119/b7ff1207/attachment.html>

Sorry for my delay.

On 11/19, Chris Lattner wrote:
> 
> 
> > On Nov 19, 2019, at 9:04 AM, Doerfert, Johannes <jdoerfert at
anl.gov> wrote:
> > 
> >>> 
> >>> 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).
> 
> What are the other things?  Naming is often helped by having examples
> from the broader pool that will shape this.  It will also be helpful
> to understand what would be “in” vs “out” of scope for this over time.
One is toolchain handling, which should be available to the linker
plugin so we can do fat binary linking without going through the clang
driver.

There is a desire to share driver code in here as well, Peter and Mark
can probably elaborate on that.

I predict we find more use cases over time.
> >> 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?
> 
> Sure,
So `lib/Frontend/OpenMP` for the OpenMP specific part seems to be a
popular option. I'd like to go ahead with this soon, please let me know
if there is disagreement. FWIW, it should be easy to rename/move the
code later anyway.
-------------- 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/20191125/7fccd157/attachment.sig>