[flang-dev] [cfe-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM
Timothy Keith via flang-dev
flang-dev at lists.llvm.org
Fri Jun 12 07:25:47 PDT 2020
For those of us not familiar with clang internals, it would be helpful if you could describe the parts of clang that you're considering sharing and explain what existing code they would replace in flang (if any) and what benefits we gain by sharing them.
In particular, these were mentioned previously: DiagnosticsEngine, SourceManager, SourceLocation, FileManager, VFS
Thanks,
Tim
On 6/12/20, 3:25 AM, "flang-dev on behalf of Andrzej Warzynski via flang-dev" <flang-dev-bounces at lists.llvm.org on behalf of flang-dev at lists.llvm.org> wrote:
External email: Use caution opening links or attachments
FYI: this RFC will be discussed in the next Flang Technical Community
call: http://lists.llvm.org/pipermail/flang-dev/2020-June/000379.html
-Andrzej
On 11/06/2020 23:06, Doerfert, Johannes wrote:
> On 6/11/20 4:04 PM, James Y Knight wrote:
>> I think the expectation is that LLVM remains at the bottom of the
>> dependency tree, with frontend-support depending on LLVM, and Clang and
>> Flang depending on frontend-support (and LLVM).
>>
>> Not everything which makes sense to share between clang and flang makes
>> sense to be part of llvm core. E.g., implementation of a GCC-compatible
>> command-line compiler-driver seems like it would be very much out-of-place
>> in llvm core.
>
> That clears things up, thanks a lot. So we could have a frontend-support
>
> subproject for non-LLVM(-IR) related things and `llvm/lib/Frontend` for
>
> LLVM(-IR) related stuff, e.g., IR generation parts.
>
>
> Thanks,
>
> Johannes
>
>
>> On Thu, Jun 11, 2020 at 10:28 AM Doerfert, Johannes via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On 6/11/20 3:32 AM, Andrzej Warzynski wrote:
>>>>
>>>> On 11/06/2020 00:49, Michael Kruse wrote:
>>>>> Am Mi., 10. Juni 2020 um 10:04 Uhr schrieb Doerfert, Johannes via
>>>>> flang-dev <flang-dev at lists.llvm.org>:
>>>>>> I'm not against a subproject *but* if we also move the existing
>>>>>> llvm/lib/Frontend stuff, that would introduce a dependence from
>>>>>> llvm-core to this project, which I think is uncommon. We could also
>>>>>> have
>>>>>> both. At the end of the day it depends on the benefit we would get from
>>>>>> an independent subproject.
>>>>> If we have non-conditional dependencies llvm-core->frontend-support
>>>>> and frontend-support->llvm-core, what advantage is there left of
>>>>> making frontend-support a subproject? Both of them are required all
>>>>> the time.
>>>>>
>>>>> Michael
>>>>>
>>>> Thanks for the feedback! It sounds like we should keep
>>>> llvm/lib/Frontend in LLVM and `frontend-support` would be a new
>>>> subproject for things unrelated to LLVM IR.
>>> Sure, if we expect usage of such a subproject without llvm-core. (Maybe
>>> there are other reasons to separate it but I'm not sure I understood them.)
>>>
>>>
>>> Thanks,
>>>
>>> Johannes
>>>
>>>
>>>> -Andrzej
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>
_______________________________________________
flang-dev mailing list
flang-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
More information about the flang-dev
mailing list