thr3ads.net - llvm dev - [llvm-dev] [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM [Jun 2020]

If this information is useful, please help other people find it:
Share via:

Doerfert, Johannes via llvm-dev

2020-Jun-11 22:06 UTC

[llvm-dev] [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

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
>>

Andrzej Warzynski via llvm-dev

2020-Jun-12 10:24 UTC

head link

[llvm-dev] [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

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
>>>
>

Timothy Keith via llvm-dev

2020-Jun-12 14:25 UTC

head link

[llvm-dev] [flang-dev] [cfe-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

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

llvm dev - Jun 2020 - [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

[llvm-dev] [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

[llvm-dev] [cfe-dev] [flang-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

[llvm-dev] [flang-dev] [cfe-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM