[llvm-dev] [RFC] Create llvm/lib/Frontend
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 14 11:19:30 PST 2019
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  (and
> >> related
> >> code ) 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) .
> >> 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
> >>  https://reviews.llvm.org/D69853
> >>  https://reviews.llvm.org/D69785
> >>  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
Argonne National Laboratory
Lemont, IL 60439, USA
jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the llvm-dev