[llvm-dev] [RFC] Create llvm/lib/Frontend
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 14 09:58:53 PST 2019
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
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.
>  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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev