Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
Hey Peter - would you be able to link to/describe the history on this process/decision. I can find one old thread where this was first proposed ( http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with some general positive responses and a lot of questions.

I see there's a flang-dev list, though I'm not sure where code review is happening (is there flang-commits or equivalent?) as there's not much chatter on the mailing list that I can see.

& I'm a bit concerned about flang, already a project with no LLVM API usage, it seems, and a community that doesn't currently look like it has much overlap with the LLVM developer community (a very rough glance at flang-dev participants, but I could be wrong - the LLVM community is large, to be sure) - I'm concerned that this might create a not very well integrated community, as we saw in the past with lldb, for instance.

- Dave

On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <[hidden email]> wrote:
Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
On 01/07, David Blaikie via llvm-dev wrote:
> Hey Peter - would you be able to link to/describe the history on this
> process/decision. I can find one old thread where this was first proposed (
> http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
> some general positive responses and a lot of questions.
>
> I see there's a flang-dev list, though I'm not sure where code review is
> happening (is there flang-commits or equivalent?) as there's not much
> chatter on the mailing list that I can see.

There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.

> & I'm a bit concerned about flang, already a project with no LLVM API
> usage, it seems, and a community that doesn't currently look like it has
> much overlap with the LLVM developer community (a very rough glance at
> flang-dev participants, but I could be wrong - the LLVM community is large,
> to be sure) - I'm concerned that this might create a not very well
> integrated community, as we saw in the past with lldb, for instance.

I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.

On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!

The API usage is a valid concern, among others, which will require code
changes in the near future.

[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html

Thanks,
  Johannes

> On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
> [hidden email]> wrote:
>
> > Hi All,
> >
> > As discussed before Christmas, this is a reminder that we intend to
> > merge flang on the 13th January (next Monday) before the llvm-10 branch.
> > At the moment I'm proposing to do it at 10am GMT. I can be flexible on
> > this point if it requires close coordination with anyone in another
> > timezone, just let me know.
> >
> > Previous discussion was in [llvm-dev] Flang landing in the monorepo
> > <http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.
> >
> > The current plan of action is summarized at
> > <https://github.com/flang-compiler/f18/issues/876>.
> >
> > The result will look a lot like the recent MLIR merge from 24th Dec:
> > <https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
> > 0f0d0ed1c78 in the llvm-project monorepo.
> >
> > Once it is done I'll mail the list. If you want to coordinate with me,
> > please get in touch.
> >
> > Regards,
> >
> > - Peter
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >

> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

[hidden email]

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev


On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote:
On 01/07, David Blaikie via llvm-dev wrote:
Hey Peter - would you be able to link to/describe the history on this
process/decision. I can find one old thread where this was first proposed (
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
some general positive responses and a lot of questions.

I see there's a flang-dev list, though I'm not sure where code review is
happening (is there flang-commits or equivalent?) as there's not much
chatter on the mailing list that I can see.
There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.

& I'm a bit concerned about flang, already a project with no LLVM API
usage, it seems, and a community that doesn't currently look like it has
much overlap with the LLVM developer community (a very rough glance at
flang-dev participants, but I could be wrong - the LLVM community is large,
to be sure) - I'm concerned that this might create a not very well
integrated community, as we saw in the past with lldb, for instance.
I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.


I'll add to this that a number of us who have been involved with LLVM for a long time are involved in guiding the Flang project. While it's certainly true that a few of the people working hard on Flang are new to the LLVM community, there is a reasonable overlap with the existing LLVM community in the overall effort.



On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!

The API usage is a valid concern, among others, which will require code
changes in the near future.

[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html


The other thing that I'll add here is that the existing Flang development has been broad and not deep - the development started with the lexical analysis (and preprocessor), then the semantic analysis, and so on. It is only very recently that any work on actual code generation has begun, and there, the initial focus has been on targeting LLVM via MLIR. I'm not saying that there aren't more places to use LLVM APIs (e.g., filesystem abstractions, ADT, etc.) -- there are -- but that's something we're planning to improve over time.

At a high level, however, the whole point of this Flang project is produce an LLVM-community-integrated Fortran frontend for LLVM. The current developers of the project, which is a growing community, are committed to realizing that outcome and are open to feedback on code structure, API usage, and other aspects of integrating with the rest of the LLVM project.

 -Hal



Thanks,
  Johannes

On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
[hidden email]> wrote:

Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
Hi Hal,

On Tue, Jan 7, 2020 at 3:38 PM Finkel, Hal J. via llvm-dev <[hidden email]> wrote:


On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote:
On 01/07, David Blaikie via llvm-dev wrote:
Hey Peter - would you be able to link to/describe the history on this
process/decision. I can find one old thread where this was first proposed (
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
some general positive responses and a lot of questions.

I see there's a flang-dev list, though I'm not sure where code review is
happening (is there flang-commits or equivalent?) as there's not much
chatter on the mailing list that I can see.
There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.

& I'm a bit concerned about flang, already a project with no LLVM API
usage, it seems, and a community that doesn't currently look like it has
much overlap with the LLVM developer community (a very rough glance at
flang-dev participants, but I could be wrong - the LLVM community is large,
to be sure) - I'm concerned that this might create a not very well
integrated community, as we saw in the past with lldb, for instance.
I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.


I'll add to this that a number of us who have been involved with LLVM for a long time are involved in guiding the Flang project. While it's certainly true that a few of the people working hard on Flang are new to the LLVM community, there is a reasonable overlap with the existing LLVM community in the overall effort.


On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!

The API usage is a valid concern, among others, which will require code
changes in the near future.

[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html


The other thing that I'll add here is that the existing Flang development has been broad and not deep - the development started with the lexical analysis (and preprocessor), then the semantic analysis, and so on. It is only very recently that any work on actual code generation has begun, and there, the initial focus has been on targeting LLVM via MLIR. I'm not saying that there aren't more places to use LLVM APIs (e.g., filesystem abstractions, ADT, etc.) -- there are -- but that's something we're planning to improve over time.

At a high level, however, the whole point of this Flang project is produce an LLVM-community-integrated Fortran frontend for LLVM. The current developers of the project, which is a growing community, are committed to realizing that outcome and are open to feedback on code structure, API usage, and other aspects of integrating with the rest of the LLVM project.

I added you to the original thread when I was replying because I knew you were around this effort, it might be nice to see if you can respond to the other thread too.

A lot of my concerns are echoed by David here and I have additional concerns as well. I don't think the project is ready for inclusion into the main llvm tree as I don't see the point right now. There's nothing llvm about it.

-eric
 

 -Hal


Thanks,
  Johannes

On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
[hidden email]> wrote:

Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev


On Tue, Jan 7, 2020 at 5:29 PM Eric Christopher <[hidden email]> wrote:
Hi Hal,

On Tue, Jan 7, 2020 at 3:38 PM Finkel, Hal J. via llvm-dev <[hidden email]> wrote:


On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote:
On 01/07, David Blaikie via llvm-dev wrote:
Hey Peter - would you be able to link to/describe the history on this
process/decision. I can find one old thread where this was first proposed (
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
some general positive responses and a lot of questions.

I see there's a flang-dev list, though I'm not sure where code review is
happening (is there flang-commits or equivalent?) as there's not much
chatter on the mailing list that I can see.
There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.

& I'm a bit concerned about flang, already a project with no LLVM API
usage, it seems, and a community that doesn't currently look like it has
much overlap with the LLVM developer community (a very rough glance at
flang-dev participants, but I could be wrong - the LLVM community is large,
to be sure) - I'm concerned that this might create a not very well
integrated community, as we saw in the past with lldb, for instance.
I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.


I'll add to this that a number of us who have been involved with LLVM for a long time are involved in guiding the Flang project. While it's certainly true that a few of the people working hard on Flang are new to the LLVM community, there is a reasonable overlap with the existing LLVM community in the overall effort.


On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!

The API usage is a valid concern, among others, which will require code
changes in the near future.

[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html


The other thing that I'll add here is that the existing Flang development has been broad and not deep - the development started with the lexical analysis (and preprocessor), then the semantic analysis, and so on. It is only very recently that any work on actual code generation has begun, and there, the initial focus has been on targeting LLVM via MLIR. I'm not saying that there aren't more places to use LLVM APIs (e.g., filesystem abstractions, ADT, etc.) -- there are -- but that's something we're planning to improve over time.

At a high level, however, the whole point of this Flang project is produce an LLVM-community-integrated Fortran frontend for LLVM. The current developers of the project, which is a growing community, are committed to realizing that outcome and are open to feedback on code structure, API usage, and other aspects of integrating with the rest of the LLVM project.

I added you to the original thread when I was replying because I knew you were around this effort, it might be nice to see if you can respond to the other thread too.

A lot of my concerns are echoed by David here and I have additional concerns as well. I don't think the project is ready for inclusion into the main llvm tree as I don't see the point right now. There's nothing llvm about it.


To elaborate a bit because this almost assuredly comes off poorly (and I apologize):

I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.

Thanks.

-eric
 
-eric
 

 -Hal


Thanks,
  Johannes

On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
[hidden email]> wrote:

Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev

Hi Eric, David, all

 

I work with Peter at Arm in a team of 5 engineers working on F18, and will continue as it becomes llvm-project/flang. We depend on Fortran support in (PGI/Nvidia) flang for our commercial Fortran compiler and will move over to llvm-project/flang (I'll call it Flang from now on) when it is ready so we are committed long-term to the technology and the community. We have a further 12 or so engineers working on LLVM core codegen, mostly for Arm’s SVE architecture, and we have a long-term involvement and commitment to the LLVM project as a whole.

 

I totally agree with your points that Flang as it stands is not fully integrated into LLVM. Hal has explained the issue about Flang not using LLVM APIs for codegen so hopefully you will agree that will get better over time. The next large development in Flang will be to add the lowering code from the syntax tree to MLIR, which is now an LLVM API. This code is being prototyped in a separate branch of Flang [1], but Eric at Nvidia will start to land the changes soon.

 

I think your point on usage of LLVM data structures and support libraries is spot on and we need to take that on board. Over time we want Flang to use more of the common LLVM infrastructure and I think that being a part of the monorepo should help this to happen.

 

At Arm, we have worked on integrating Flang into Clang's driver [2] [3] [4] and we are trying to follow the existing structure of the driver and to take advantage of common functionality as much as possible in that exercise. I should also say that we are working on a patch to Flang that adds testing using llvm-lit/FileCheck in the style of llvm projects [5]. We'll be adding all tests for the new driver as lit tests. We are also working internally on porting over the existing Flang tests that use bespoke scripts to using lit (this code has not made it to github yet.)

 

As a community, we are also trying as much as possible to follow the LLVM coding style in Flang [6] and other design principles like modularity so each part of the compiler can be tested in isolation.

 

Our rationale for contributing Flang to LLVM at this point rather than waiting is so that we can work on integrating it more closely with LLVM as a community effort, in tree. The longer we develop Flang as a separate entity, the more its community ethos, its processes, its code style and structure, etc. will likely diverge from the LLVM norms. We think that the eventual inclusion Flang would be harder on that side even though the code itself may make more use of LLVM APIs and datastructures. I don’t think there is a right or wrong answer but this is the position we support at Arm and we look forward to working with the community to improve Flang in the ways you suggest.

 

Yours

Rich

 

[1] https://github.com/schweitzpgi/f18/tree/f18

[2] https://reviews.llvm.org/D63607

[3] https://github.com/flang-compiler/f18/pull/759

[4] https://github.com/flang-compiler/f18/pull/762 and https://github.com/flang-compiler/f18/pull/763

[5] https://github.com/flang-compiler/f18/pull/861

[6] https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2Bstyle.md

 

 

From: llvm-dev <[hidden email]> On Behalf Of Eric Christopher via llvm-dev
Sent: 8 January, 2020 01:48
To: Finkel, Hal J. <[hidden email]>
Cc: llvm-dev <[hidden email]>; Mike Edwards <[hidden email]>
Subject: Re: [llvm-dev] Flang landing in the monorepo - next Monday!

 

 

 

On Tue, Jan 7, 2020 at 5:29 PM Eric Christopher <[hidden email]> wrote:

Hi Hal,

 

On Tue, Jan 7, 2020 at 3:38 PM Finkel, Hal J. via llvm-dev <[hidden email]> wrote:

 

On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote:

On 01/07, David Blaikie via llvm-dev wrote:
Hey Peter - would you be able to link to/describe the history on this
process/decision. I can find one old thread where this was first proposed (
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
some general positive responses and a lot of questions.
 
I see there's a flang-dev list, though I'm not sure where code review is
happening (is there flang-commits or equivalent?) as there's not much
chatter on the mailing list that I can see.
There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.
 
& I'm a bit concerned about flang, already a project with no LLVM API
usage, it seems, and a community that doesn't currently look like it has
much overlap with the LLVM developer community (a very rough glance at
flang-dev participants, but I could be wrong - the LLVM community is large,
to be sure) - I'm concerned that this might create a not very well
integrated community, as we saw in the past with lldb, for instance.
I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.

 

I'll add to this that a number of us who have been involved with LLVM for a long time are involved in guiding the Flang project. While it's certainly true that a few of the people working hard on Flang are new to the LLVM community, there is a reasonable overlap with the existing LLVM community in the overall effort.

 

On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!
 
The API usage is a valid concern, among others, which will require code
changes in the near future.
 
[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html

 

The other thing that I'll add here is that the existing Flang development has been broad and not deep - the development started with the lexical analysis (and preprocessor), then the semantic analysis, and so on. It is only very recently that any work on actual code generation has begun, and there, the initial focus has been on targeting LLVM via MLIR. I'm not saying that there aren't more places to use LLVM APIs (e.g., filesystem abstractions, ADT, etc.) -- there are -- but that's something we're planning to improve over time.

At a high level, however, the whole point of this Flang project is produce an LLVM-community-integrated Fortran frontend for LLVM. The current developers of the project, which is a growing community, are committed to realizing that outcome and are open to feedback on code structure, API usage, and other aspects of integrating with the rest of the LLVM project.

I added you to the original thread when I was replying because I knew you were around this effort, it might be nice to see if you can respond to the other thread too.

 

A lot of my concerns are echoed by David here and I have additional concerns as well. I don't think the project is ready for inclusion into the main llvm tree as I don't see the point right now. There's nothing llvm about it.

 

 

To elaborate a bit because this almost assuredly comes off poorly (and I apologize):

 

I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.

 

Thanks.

 

-eric

 

-eric

 

 -Hal

 

Thanks,
  Johannes
 
On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
[hidden email]> wrote:
 
Hi All,
 
As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.
 
Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.
 
The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.
 
The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.
 
Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.
 
Regards,
 
- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
 
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev


On Wed, Jan 8, 2020 at 10:32 AM Richard Barton via llvm-dev <[hidden email]> wrote:

Hi Eric, David, all

 

I work with Peter at Arm in a team of 5 engineers working on F18, and will continue as it becomes llvm-project/flang. We depend on Fortran support in (PGI/Nvidia) flang for our commercial Fortran compiler and will move over to llvm-project/flang (I'll call it Flang from now on) when it is ready so we are committed long-term to the technology and the community. We have a further 12 or so engineers working on LLVM core codegen, mostly for Arm’s SVE architecture, and we have a long-term involvement and commitment to the LLVM project as a whole.

 

I totally agree with your points that Flang as it stands is not fully integrated into LLVM. Hal has explained the issue about Flang not using LLVM APIs for codegen so hopefully you will agree that will get better over time. The next large development in Flang will be to add the lowering code from the syntax tree to MLIR, which is now an LLVM API. This code is being prototyped in a separate branch of Flang [1], but Eric at Nvidia will start to land the changes soon.

 

I think your point on usage of LLVM data structures and support libraries is spot on and we need to take that on board. Over time we want Flang to use more of the common LLVM infrastructure and I think that being a part of the monorepo should help this to happen.

 

At Arm, we have worked on integrating Flang into Clang's driver [2] [3] [4] and we are trying to follow the existing structure of the driver and to take advantage of common functionality as much as possible in that exercise. I should also say that we are working on a patch to Flang that adds testing using llvm-lit/FileCheck in the style of llvm projects [5]. We'll be adding all tests for the new driver as lit tests. We are also working internally on porting over the existing Flang tests that use bespoke scripts to using lit (this code has not made it to github yet.)

 

As a community, we are also trying as much as possible to follow the LLVM coding style in Flang [6] and other design principles like modularity so each part of the compiler can be tested in isolation.

 

Our rationale for contributing Flang to LLVM at this point rather than waiting is so that we can work on integrating it more closely with LLVM as a community effort, in tree. The longer we develop Flang as a separate entity, the more its community ethos, its processes, its code style and structure, etc. will likely diverge from the LLVM norms. We think that the eventual inclusion Flang would be harder on that side even though the code itself may make more use of LLVM APIs and datastructures. I don’t think there is a right or wrong answer but this is the position we support at Arm and we look forward to working with the community to improve Flang in the ways you suggest.


I'll say, FWIW - that I tend to agree with this, that I'm happy to see this developed further in tree, even if it's not LLVM-y right now. Having more of the revision history in-tree, bisectable, etc, seems good to me & my biggest concern is around community cross pollination to make sure it doesn't end up isolated. I know some of the names of the folks working across f18/flang and LLVM & hope that continues/grows (& of course this shouldn't be dependent on who's names I recognize or don't - the community is large enough that there are going to be different fairly non-overlapping subgroups, etc).

(just chiming in here to say I'm personally not opposed to flang going in-tree as-is - my reason for the earlier email was to express a few broad concerns I'd heard from the community, get some other folks in here for visibility & make sure this wasn't just a "it's happening because no one's paying attention" kind of thing)

(as for style - at least a few things that stood out at a glance: a bunch of else-after-return, and a lot of bracing on single line blocks (technically that latter one isn't written in the style guide, but it's pretty pervasive across the LLVM project))
 

 

Yours

Rich

 

[1] https://github.com/schweitzpgi/f18/tree/f18

[2] https://reviews.llvm.org/D63607

[3] https://github.com/flang-compiler/f18/pull/759

[4] https://github.com/flang-compiler/f18/pull/762 and https://github.com/flang-compiler/f18/pull/763

[5] https://github.com/flang-compiler/f18/pull/861

[6] https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2Bstyle.md

 

 

From: llvm-dev <[hidden email]> On Behalf Of Eric Christopher via llvm-dev
Sent: 8 January, 2020 01:48
To: Finkel, Hal J. <[hidden email]>
Cc: llvm-dev <[hidden email]>; Mike Edwards <[hidden email]>
Subject: Re: [llvm-dev] Flang landing in the monorepo - next Monday!

 

 

 

On Tue, Jan 7, 2020 at 5:29 PM Eric Christopher <[hidden email]> wrote:

Hi Hal,

 

On Tue, Jan 7, 2020 at 3:38 PM Finkel, Hal J. via llvm-dev <[hidden email]> wrote:

 

On 1/7/20 4:38 PM, Doerfert, Johannes via llvm-dev wrote:

On 01/07, David Blaikie via llvm-dev wrote:
Hey Peter - would you be able to link to/describe the history on this
process/decision. I can find one old thread where this was first proposed (
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html ) with
some general positive responses and a lot of questions.
 
I see there's a flang-dev list, though I'm not sure where code review is
happening (is there flang-commits or equivalent?) as there's not much
chatter on the mailing list that I can see.
There is a flang-commits. We have everything set up to use Phabricator
as MLIR did.
 
& I'm a bit concerned about flang, already a project with no LLVM API
usage, it seems, and a community that doesn't currently look like it has
much overlap with the LLVM developer community (a very rough glance at
flang-dev participants, but I could be wrong - the LLVM community is large,
to be sure) - I'm concerned that this might create a not very well
integrated community, as we saw in the past with lldb, for instance.
I think I mentioned this before but some people are waiting for the move
to be able to actually participate in the Flang development. So the
current github contributions do not necessarily reflect the LLVM
developers that will be involved.

 

I'll add to this that a number of us who have been involved with LLVM for a long time are involved in guiding the Flang project. While it's certainly true that a few of the people working hard on Flang are new to the LLVM community, there is a reasonable overlap with the existing LLVM community in the overall effort.

 

On flang-dev [0] we have long term LLVM developers and people that join
the LLVM developers community with the merge of Flang but even those
already actively participated at the LLVM-Dev!
 
The API usage is a valid concern, among others, which will require code
changes in the near future.
 
[0] http://lists.llvm.org/pipermail/flang-dev/2019-December/author.html

 

The other thing that I'll add here is that the existing Flang development has been broad and not deep - the development started with the lexical analysis (and preprocessor), then the semantic analysis, and so on. It is only very recently that any work on actual code generation has begun, and there, the initial focus has been on targeting LLVM via MLIR. I'm not saying that there aren't more places to use LLVM APIs (e.g., filesystem abstractions, ADT, etc.) -- there are -- but that's something we're planning to improve over time.

At a high level, however, the whole point of this Flang project is produce an LLVM-community-integrated Fortran frontend for LLVM. The current developers of the project, which is a growing community, are committed to realizing that outcome and are open to feedback on code structure, API usage, and other aspects of integrating with the rest of the LLVM project.

I added you to the original thread when I was replying because I knew you were around this effort, it might be nice to see if you can respond to the other thread too.

 

A lot of my concerns are echoed by David here and I have additional concerns as well. I don't think the project is ready for inclusion into the main llvm tree as I don't see the point right now. There's nothing llvm about it.

 

 

To elaborate a bit because this almost assuredly comes off poorly (and I apologize):

 

I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.

 

Thanks.

 

-eric

 

-eric

 

 -Hal

 

Thanks,
  Johannes
 
On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <
[hidden email]> wrote:
 
Hi All,
 
As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.
 
Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.
 
The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.
 
The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.
 
Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.
 
Regards,
 
- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
 
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev
<[hidden email]> wrote:
> I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.

(Disclaimer: Not taking sides, I have no stake in Flang or Fortran).

I think David's comparison to LLDB is interesting. It started very
distant, and then with time merged with the codebase and now it's a
full fledged LLVM project.

The current Flang (F18) is meant to be much closer to LLVM than the
previous one, and the whole mindset was afaik to keep it that way. In
the same way that LLDB once was.

I do agree with Hal that there is a small but significant overlap of
communities, and I do agree with Rick that the longer it stays
separate, the harder it will be for that sub-community.

But LLDB started at a time where "being an LLVM project" was mostly
about being in our SVN repo. There was no mono-repo, and the cost of
being there was lower-ish.

I believe that can be solved with build semantics (CMake stuff?), not
a big problem, so the main issue is about community: will the project
move fast enough towards LLVM integration or will it dangle with
downstream implementations and be mostly useless upstream?

I think we have enough people that care about Flang publicly putting
their names forward. This makes me assume the former, so I'm
personally ok with the merge.

If it happens before the current branch or not, will depend on how
fast they're willing to work towards a working Fortran front-end.

I'd assume that, once it's in, the next release (July/20) would have
to have something minimally decent. But that's not a strong opinion,
so, salt & pepper.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
Hal, Eric, Johannes, David and Peter, 

I lead the development of OpenMP for AMD GPUs and work with others at AMD who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly appreciate your efforts to move the development of flang into a subproject in the llvm-project repository and to integrate this development effort into the overall LLVM development community.   

Like most commercial companies, we have certain procedures (some legal) to participate in open source projects.  Since AMD has already engaged in LLVM development, adding flang as an LLVM subproject makes it much easier to participate in the development of flang.    I look forward to my team getting more involved in the development of flang now that it is part of LLVM.

I would respectfully disagree with "There's nothing llvm about it".  Flang uses the clang offloading architecture used by cuda, hip, and openmp-target.  And the runtime will use both libomp and libomptarget runtimes found in the llvm project openmp.   While flang frontend may not immediately use clang -cc1 parsing and codegen, the upstream clang driver already supports a flang toolchain. See clang/lib/Driver/Types.cpp and  clang/lib/Driver/ToolChains/Flang.cpp.

I think it is better for flang to join LLVM sooner than later.  This will help flang developers better adopt llvm development practices.  For example, an earlier variant of flang written in c, generated LLVM-IR without using llvm::IRBuilder.  This is because the origin of that source was from a non-LLVM project. This architecture was rejected partly because it was not llvm enough.  This lead to the creation of the f18 C++ project which will use llvm::IRbuilder.  F18 is the flang that I expect and hope to land in monorepo next Monday.  

I am also AMD's representative to the OpenMP Architecture Review Board.  Adding flang is an important step to completely cover the OpenMP specification for c, C++, and FORTRAN in LLVM.    

I agree, flang has a long way to go.  But I believe there is enough critical mass with flang to join the LLVM development now. 

Thank you
 
Greg Rodgers

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
Thanks to everyone for the feedback — both concerns and support.

Let me add a perspective as someone who has been responsible for helping to start part of the initial push and finding funding for a portion of the Flang/f18 efforts to date.  From the outset our mindset was to get Flang to a point where it was worthy of becoming a part of the LLVM community.  So making Flang a successful part of the LLVM community has been a major factor in our viewpoint from the outset.  That may not be reflected in the nature of the code base as some might prefer to see it today but I personally view the monorepo landing as the point in time where Flang actually becomes the community’s project.  

For exactly the same reasons Greg mentions, having Flang in the monorepo will help many of us avoid hassles to be able to contribute to the code base.  Something that makes the formation of a supporting subset of the community extremely difficult.  I strongly believe the longer Flang stays separated from the monorepo the harder it will become to transition — simply because the odds that the steps taken to meet target deliverables and features won’t necessarily be addressed as part of the community’s discussions (I think this thread has in part shown that we’re already here today and need to move beyond it sooner rather than later).  The steps of landing Flang into the monorepo should simply be viewed as the very first steps and should in no way be considered to be the final ones.

Thanks,

—Pat


> On Jan 8, 2020, at 12:15 PM, Gregory Rodgers via llvm-dev <[hidden email]> wrote:
>
> Hal, Eric, Johannes, David and Peter,
>
> I lead the development of OpenMP for AMD GPUs and work with others at AMD who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly appreciate your efforts to move the development of flang into a subproject in the llvm-project repository and to integrate this development effort into the overall LLVM development community.  
>
> Like most commercial companies, we have certain procedures (some legal) to participate in open source projects.  Since AMD has already engaged in LLVM development, adding flang as an LLVM subproject makes it much easier to participate in the development of flang.    I look forward to my team getting more involved in the development of flang now that it is part of LLVM.
>
> I would respectfully disagree with "There's nothing llvm about it".  Flang uses the clang offloading architecture used by cuda, hip, and openmp-target.  And the runtime will use both libomp and libomptarget runtimes found in the llvm project openmp.   While flang frontend may not immediately use clang -cc1 parsing and codegen, the upstream clang driver already supports a flang toolchain. See clang/lib/Driver/Types.cpp and  clang/lib/Driver/ToolChains/Flang.cpp.
>
> I think it is better for flang to join LLVM sooner than later.  This will help flang developers better adopt llvm development practices.  For example, an earlier variant of flang written in c, generated LLVM-IR without using llvm::IRBuilder.  This is because the origin of that source was from a non-LLVM project. This architecture was rejected partly because it was not llvm enough.  This lead to the creation of the f18 C++ project which will use llvm::IRbuilder.  F18 is the flang that I expect and hope to land in monorepo next Monday.  
>
> I am also AMD's representative to the OpenMP Architecture Review Board.  Adding flang is an important step to completely cover the OpenMP specification for c, C++, and FORTRAN in LLVM.    
>
> I agree, flang has a long way to go.  But I believe there is enough critical mass with flang to join the LLVM development now.
>
> Thank you
>  
> Greg Rodgers
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
Hi Gregory,

(As a note, you didn't reply to the thread so I didn't see this until now.)

As I said in my previous thread: "You don't use a single llvm header anywhere" that's a pretty low bar for "looks like an llvm project" - and nothing has changed in the 3 weeks since I sent my earlier message. "We plan on" isn't a very compelling argument for "looks like llvm".  

As far as the current use in the clang driver: Honestly I don't think you should be using the clang driver and had I seen I probably wouldn't have accepted those patches either. I think it would be better off to turn parts of the driver you might need into a separable library rather than include fortran support into a "c based languages" driver and will probably try to dig up that patch set and comment.

To be clear: I support the idea of a fortran compiler in llvm and appreciate that you want to do it right. I would like to see a plan of attack before we talk about imminently putting things in as relying on the community to adopt llvm development practices and libraries seems to put a lot of weight in the community rather than on the project that wants to move in.

Thanks.

-eric


On Wed, Jan 8, 2020 at 11:16 AM Gregory Rodgers via llvm-dev <[hidden email]> wrote:
Hal, Eric, Johannes, David and Peter, 

I lead the development of OpenMP for AMD GPUs and work with others at AMD who support OpenMP on AMD CPUs. On behalf of our development teams, we greatly appreciate your efforts to move the development of flang into a subproject in the llvm-project repository and to integrate this development effort into the overall LLVM development community.   

Like most commercial companies, we have certain procedures (some legal) to participate in open source projects.  Since AMD has already engaged in LLVM development, adding flang as an LLVM subproject makes it much easier to participate in the development of flang.    I look forward to my team getting more involved in the development of flang now that it is part of LLVM.

I would respectfully disagree with "There's nothing llvm about it".  Flang uses the clang offloading architecture used by cuda, hip, and openmp-target.  And the runtime will use both libomp and libomptarget runtimes found in the llvm project openmp.   While flang frontend may not immediately use clang -cc1 parsing and codegen, the upstream clang driver already supports a flang toolchain. See clang/lib/Driver/Types.cpp and  clang/lib/Driver/ToolChains/Flang.cpp.

I think it is better for flang to join LLVM sooner than later.  This will help flang developers better adopt llvm development practices.  For example, an earlier variant of flang written in c, generated LLVM-IR without using llvm::IRBuilder.  This is because the origin of that source was from a non-LLVM project. This architecture was rejected partly because it was not llvm enough.  This lead to the creation of the f18 C++ project which will use llvm::IRbuilder.  F18 is the flang that I expect and hope to land in monorepo next Monday.  

I am also AMD's representative to the OpenMP Architecture Review Board.  Adding flang is an important step to completely cover the OpenMP specification for c, C++, and FORTRAN in LLVM.    

I agree, flang has a long way to go.  But I believe there is enough critical mass with flang to join the LLVM development now. 

Thank you
 
Greg Rodgers
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev wrote:
> As far as the current use in the clang driver: Honestly I don't think you
> should be using the clang driver and had I seen I probably wouldn't have
> accepted those patches either. I think it would be better off to turn parts
> of the driver you might need into a separable library rather than include
> fortran support into a "c based languages" driver and will probably try to
> dig up that patch set and comment.

I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.

Joerg
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev


On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <[hidden email]> wrote:
On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev wrote:
> As far as the current use in the clang driver: Honestly I don't think you
> should be using the clang driver and had I seen I probably wouldn't have
> accepted those patches either. I think it would be better off to turn parts
> of the driver you might need into a separable library rather than include
> fortran support into a "c based languages" driver and will probably try to
> dig up that patch set and comment.

I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.


This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.

Thanks

-eric 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev


On 1/8/20 7:52 PM, Eric Christopher via llvm-dev wrote:


On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <[hidden email]> wrote:
On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev wrote:
> As far as the current use in the clang driver: Honestly I don't think you
> should be using the clang driver and had I seen I probably wouldn't have
> accepted those patches either. I think it would be better off to turn parts
> of the driver you might need into a separable library rather than include
> fortran support into a "c based languages" driver and will probably try to
> dig up that patch set and comment.

I disagree on this part quite a bit. First of all, there is quite a bit
code in the wild that expects at least basic support in the "gcc"
frontend for handling Fortran. Additionally, there is a very significant
overlap in the platform handling and little Fortran specific logic
assuming that we don't end up with hundreds of tuning options in the
frontend. That was the biggest concern for me with the first flang
patches to the clang driver: insane amount of fine-tuning flags and
magic number mappings.


This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.


First, I completely agree that we should have a "frontend driver" library in LLVM. There are lots of frontends that need to know how to call the linker and make a executable program, shared library, etc., and we should have some reusable infrastructure for that.

In this case, however, Fortran is somewhat of a special case for historical reasons. To emulate gcc, our driver needs to know how to invoke a Fortran compiler. Considering that, especially considering our long-standing support for being a driver for gfortran for this reason, and the other similarities in the compilation models, having this in Clang seems reasonable to me. The reality is that, in terms of toolchains, the triple of C/C++/Fortran go together for a significant set of programming environments, and there has long been a coupling at this driver level (at large).

 -Hal



Thanks

-eric 

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
FYI to everyone: If you have things that you would like to see done
before a merge of Flang, please reply with as many details as you have
time to provide (and if you have things that you would like to see done
soon, but you're comfortable with them happening after the merge, please
share those items as well). Our Flang community technical call on Monday
morning will be dedicated to forming a concrete plan from any
yet-unaddressed items and making sure that we have a checklist to address.

Thanks again,

Hal

On 1/8/20 1:01 PM, Renato Golin wrote:

> On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev
> <[hidden email]> wrote:
>> I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.
> (Disclaimer: Not taking sides, I have no stake in Flang or Fortran).
>
> I think David's comparison to LLDB is interesting. It started very
> distant, and then with time merged with the codebase and now it's a
> full fledged LLVM project.
>
> The current Flang (F18) is meant to be much closer to LLVM than the
> previous one, and the whole mindset was afaik to keep it that way. In
> the same way that LLDB once was.
>
> I do agree with Hal that there is a small but significant overlap of
> communities, and I do agree with Rick that the longer it stays
> separate, the harder it will be for that sub-community.
>
> But LLDB started at a time where "being an LLVM project" was mostly
> about being in our SVN repo. There was no mono-repo, and the cost of
> being there was lower-ish.
>
> I believe that can be solved with build semantics (CMake stuff?), not
> a big problem, so the main issue is about community: will the project
> move fast enough towards LLVM integration or will it dangle with
> downstream implementations and be mostly useless upstream?
>
> I think we have enough people that care about Flang publicly putting
> their names forward. This makes me assume the former, so I'm
> personally ok with the merge.
>
> If it happens before the current branch or not, will depend on how
> fast they're willing to work towards a working Fortran front-end.
>
> I'd assume that, once it's in, the next release (July/20) would have
> to have something minimally decent. But that's not a strong opinion,
> so, salt & pepper.
>
> cheers,
> --renato

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
Thanks Hal, having a plan of action will alleviate my concerns completely. 

-eric

On Wed, Jan 8, 2020, 6:53 PM Finkel, Hal J. <[hidden email]> wrote:
FYI to everyone: If you have things that you would like to see done
before a merge of Flang, please reply with as many details as you have
time to provide (and if you have things that you would like to see done
soon, but you're comfortable with them happening after the merge, please
share those items as well). Our Flang community technical call on Monday
morning will be dedicated to forming a concrete plan from any
yet-unaddressed items and making sure that we have a checklist to address.

Thanks again,

Hal

On 1/8/20 1:01 PM, Renato Golin wrote:
> On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev
> <[hidden email]> wrote:
>> I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.
> (Disclaimer: Not taking sides, I have no stake in Flang or Fortran).
>
> I think David's comparison to LLDB is interesting. It started very
> distant, and then with time merged with the codebase and now it's a
> full fledged LLVM project.
>
> The current Flang (F18) is meant to be much closer to LLVM than the
> previous one, and the whole mindset was afaik to keep it that way. In
> the same way that LLDB once was.
>
> I do agree with Hal that there is a small but significant overlap of
> communities, and I do agree with Rick that the longer it stays
> separate, the harder it will be for that sub-community.
>
> But LLDB started at a time where "being an LLVM project" was mostly
> about being in our SVN repo. There was no mono-repo, and the cost of
> being there was lower-ish.
>
> I believe that can be solved with build semantics (CMake stuff?), not
> a big problem, so the main issue is about community: will the project
> move fast enough towards LLVM integration or will it dangle with
> downstream implementations and be mostly useless upstream?
>
> I think we have enough people that care about Flang publicly putting
> their names forward. This makes me assume the former, so I'm
> personally ok with the merge.
>
> If it happens before the current branch or not, will depend on how
> fast they're willing to work towards a working Fortran front-end.
>
> I'd assume that, once it's in, the next release (July/20) would have
> to have something minimally decent. But that's not a strong opinion,
> so, salt & pepper.
>
> cheers,
> --renato

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
Hi,

On Wed, Jan 8, 2020 at 6:54 PM Finkel, Hal J. via llvm-dev <[hidden email]> wrote:
FYI to everyone: If you have things that you would like to see done
before a merge of Flang, please reply with as many details as you have
time to provide (and if you have things that you would like to see done
soon, but you're comfortable with them happening after the merge, please
share those items as well). Our Flang community technical call on Monday
morning will be dedicated to forming a concrete plan from any
yet-unaddressed items and making sure that we have a checklist to address.

What is the latest/current proposed merge commit showing what will be pushed to the monorepo?
Can you make sure to prune/repack the repo before pushing?
Are the license header updated to be the LLVM license?
The test don't seem to be lit-based testing: is this part of the TODO list?

Looking forward to flang joining the monorepo!

Thanks,

-- 
Mehdi



 

Thanks again,

Hal

On 1/8/20 1:01 PM, Renato Golin wrote:
> On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev
> <[hidden email]> wrote:
>> I am in favor of having a flang front end in tree. I have concerns about the design of flang versus other front ends, the lack of llvm based library use, and a number of other things that I tried to enumerate in previous emails. I don't know if anything has changed and the responses I got back originally were "we're going to do it anyway" so it didn't leave much room for engagement.
> (Disclaimer: Not taking sides, I have no stake in Flang or Fortran).
>
> I think David's comparison to LLDB is interesting. It started very
> distant, and then with time merged with the codebase and now it's a
> full fledged LLVM project.
>
> The current Flang (F18) is meant to be much closer to LLVM than the
> previous one, and the whole mindset was afaik to keep it that way. In
> the same way that LLDB once was.
>
> I do agree with Hal that there is a small but significant overlap of
> communities, and I do agree with Rick that the longer it stays
> separate, the harder it will be for that sub-community.
>
> But LLDB started at a time where "being an LLVM project" was mostly
> about being in our SVN repo. There was no mono-repo, and the cost of
> being there was lower-ish.
>
> I believe that can be solved with build semantics (CMake stuff?), not
> a big problem, so the main issue is about community: will the project
> move fast enough towards LLVM integration or will it dangle with
> downstream implementations and be mostly useless upstream?
>
> I think we have enough people that care about Flang publicly putting
> their names forward. This makes me assume the former, so I'm
> personally ok with the merge.
>
> If it happens before the current branch or not, will depend on how
> fast they're willing to work towards a working Fortran front-end.
>
> I'd assume that, once it's in, the next release (July/20) would have
> to have something minimally decent. But that's not a strong opinion,
> so, salt & pepper.
>
> cheers,
> --renato

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev


On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <[hidden email]> wrote:
Hi All,

As discussed before Christmas, this is a reminder that we intend to
merge flang on the 13th January (next Monday) before the llvm-10 branch.

Why is it targeting pre-llvm10 branching? Are we expecting to ship anything in LLVM 10? If so I would have expected it to land much much earlier to be able to stabilize during the development phase long before the branching point.

-- 
Mehdi

 
At the moment I'm proposing to do it at 10am GMT. I can be flexible on
this point if it requires close coordination with anyone in another
timezone, just let me know.

Previous discussion was in [llvm-dev] Flang landing in the monorepo
<http://lists.llvm.org/pipermail/llvm-dev/2019-December/137661.html>.

The current plan of action is summarized at
<https://github.com/flang-compiler/f18/issues/876>.

The result will look a lot like the recent MLIR merge from 24th Dec:
<https://github.com/llvm/llvm-project/commits/0f0d0ed1c78>, commit
0f0d0ed1c78 in the llvm-project monorepo.

Once it is done I'll mail the list. If you want to coordinate with me,
please get in touch.

Regards,

- Peter
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Flang landing in the monorepo - next Monday!

Daniel Sanders via llvm-dev
In reply to this post by Daniel Sanders via llvm-dev
On 01/09, Finkel, Hal J. via llvm-dev wrote:

>
> On 1/8/20 7:52 PM, Eric Christopher via llvm-dev wrote:
>
>
> On Wed, Jan 8, 2020 at 5:42 PM Joerg Sonnenberger via llvm-dev <[hidden email]<mailto:[hidden email]>> wrote:
> > On Wed, Jan 08, 2020 at 05:35:44PM -0800, Eric Christopher via llvm-dev wrote:
> > > As far as the current use in the clang driver: Honestly I don't think you
> > > should be using the clang driver and had I seen I probably wouldn't have
> > > accepted those patches either. I think it would be better off to turn parts
> > > of the driver you might need into a separable library rather than include
> > > fortran support into a "c based languages" driver and will probably try to
> > > dig up that patch set and comment.
> >
> > I disagree on this part quite a bit. First of all, there is quite a bit
> > code in the wild that expects at least basic support in the "gcc"
> > frontend for handling Fortran. Additionally, there is a very significant
> > overlap in the platform handling and little Fortran specific logic
> > assuming that we don't end up with hundreds of tuning options in the
> > frontend. That was the biggest concern for me with the first flang
> > patches to the clang driver: insane amount of fine-tuning flags and
> > magic number mappings.
> >
> >
> > This is an absolutely fair response, but I think the answer there is making a lot of the clang driver a library and not having clang support fortran compilation.
> >
> >
> First, I completely agree that we should have a "frontend driver"
> library in LLVM. There are lots of frontends that need to know how to
> call the linker and make a executable program, shared library, etc.,
> and we should have some reusable infrastructure for that.
FWIW, that was one of the reasons why we now have `llvm/lib/Frontend`
and the corresponding libraries for the subdirectories.

In addition to frontends, the linker will probably need to know about
various bits, e.g., how to find nvcc, if we have fat-binary/offloading
support in the linker.

Cheers,
  Johannes

> In this case, however, Fortran is somewhat of a special case for
> historical reasons. To emulate gcc, our driver needs to know how to
> invoke a Fortran compiler. Considering that, especially considering
> our long-standing support for being a driver for gfortran for this
> reason, and the other similarities in the compilation models, having
> this in Clang seems reasonable to me. The reality is that, in terms of
> toolchains, the triple of C/C++/Fortran go together for a significant
> set of programming environments, and there has long been a coupling at
> this driver level (at large).



_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

signature.asc (235 bytes) Download Attachment
123