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

[Michael Spencer via llvm-dev]

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>