llvm dev - Jan 2020 - Flang landing in the monorepo - next Monday!

On Wed, 8 Jan 2020 at 01:48, Eric Christopher via llvm-dev
<llvm-dev at lists.llvm.org> 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

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
> <llvm-dev at lists.llvm.org> 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

Thanks Hal, having a plan of action will alleviate my concerns completely.

-eric

On Wed, Jan 8, 2020, 6:53 PM Finkel, Hal J. <hfinkel at anl.gov> 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
> > <llvm-dev at lists.llvm.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200108/80db6c22/attachment.html>

Hi,

On Wed, Jan 8, 2020 at 6:54 PM Finkel, Hal J. via llvm-dev <
llvm-dev at lists.llvm.org> 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
> > <llvm-dev at lists.llvm.org> 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
> 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/20200108/6c796d2f/attachment-0001.html>