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

Sun Jan 12 22:50:44 PST 2020

On Thu, Jan 9, 2020 at 4:28 AM Richard Barton via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi all
>
> Thanks for all the replies and engagement on this issue.
>
> First point, given the state of discussions today I would like to propose
> that we don't start the merge at 10:00 GMT on Monday 13th as proposed and
> we delay by at least 24 hours until after the scheduled F18 technical call
> on Monday afternoon.
>
> In order to help compile a plan of action, I've tried to compile a list of
> the concerns that folks have raised so far.
>
> I think all these have been addressed (please correct me if you think
> otherwise)
> 1. Audit trail/visibility of code review [Addressed by Peter - code has
> been reviewed [a] to F18 coding guidelines [b].
> 2. Long-term viability of Flang community and overlap with existing LLVM
> community [Hopefully Hal and Johannes replies and Greg's and Pat's and my
> reply demonstrate long-term commitment to Flang after upstreaming]
> 3. Compatibility of license [Addressed by Steve, a recent update has made
> the licenses compatible [c]]
> 4. No use of LLVM APIs and so no connection to the project [Addressed by
> Hal and me - it is the natural next step in development as Flang starts to
> generate MLIR. Nvidia are working on this now.]
>
>
The choice of MLIR is interesting - and given that there was no discussion
of it I was wondering if you have a document laying out pros/cons and what
ultimately made the decision here.

> I think these are acknowledged right now and we are actively working on
> fixes:
> 5. No use of lit in the regression tests [Arm is working on this]
> 6. Need to refactor parts of clang driver that can be shared with flang
> into a separate library [Arm is working on this, but plans to implement a
> simple driver first before refactoring to better understand the
> opportunities to do so. See Peter's RFC [d] ]
> 7. No use of LLVM utilities or standard data structures (Vector, etc.) [I
> think Pat and Eric have patches ready to go for this?]
>

I don't really consider this addressed without a plan of action (before
merge) that contains a list of standard llvm support libraries that would
be used in addition to things being removed (pretty much all use of C++ c*
headers and more?) as well as staffing and approximate ETAs.

>
> I think these are only acknowledged, with the intention to remediate post
> merge, but no concrete plan or owner at this point:
> 8. Simple deviations from the LLVM coding style
>     a. Separating public headers into include/flang
>     b. Syntactical things like braces on single line statements, comments
> on end of namespaces, etc.
>     c. .cc file extensions rather than .cpp
> 9. Bigger deviations from the LLVM coding style that are harder to fix
>     a. Early exits and not using else after return, etc.
> 10. Flang not supporting all the same C++ compilers as the rest of the
> project (even taking into account C++17 requirement)
>
As things stand we are not proposing to remediate these (issues 5 and
> greater) in the code before it is merged to LLVM next week. These issues
> will be worked on after commit.
>
>
As well as this. A plan of action isn't just a "we'll get to this" but an
actual plan :)

> Does anyone feel passionately that any of the above points need to be
> addressed in the code before we can merge?
> Does anyone feel there is anything missing from that list?
>
> Given Mehdi and Hans' query about why this needs to go into LLVM10. Unless
> anyone has any good reason, perhaps we could postpone until after the
> branch, perhaps by one week to January 20th? That would give us some more
> time to bottom out what changes need to be made before we can accept the
> code and give us time to make any changes that block inclusion (assuming
> they are suitably sized to do in this timescale). As Renato suggests, that
> would also give us the LLVM11 branching point as a natural deadline to have
> addressed the larger concerns in our list.
>
> What do people think to that proposal?
>
>
I think waiting until after the llvm 10 branch would probably be best at
this point. That will give a lot of time for cleanup and to make f18 a much
more reasonable "preview" including code generation in a forthcoming
release in about 6 mos.

-eric

> Regards
> Rich
>
> [a] https://github.com/flang-compiler/f18/pulls
> [b]
> https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2Bstyle.md
> [c]
> https://github.com/flang-compiler/f18/commit/e06be2faa64a52471b3cfb2829dc05888236aa68
> [d]  http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html
>
> > -----Original Message-----
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Renato
> > Golin via llvm-dev
> > Sent: 9 January, 2020 10:02
> > To: Hans Wennborg <hans at chromium.org>
> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Mike Edwards <medwards at llvm.org>
> > Subject: Re: [llvm-dev] Flang landing in the monorepo - next Monday!
> >
> > On Thu, 9 Jan 2020 at 08:13, Hans Wennborg via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > > > 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.
> > >
> > > I was wondering about this too. I'm not necessarily opposed, but
> > > wouldn't it make sense to target landing soon *after* the branch
> > > instead, to give it time to integrate, stabilize, and then ship in the
> > > next release?
> >
> > Usually, yes.
> >
> > I'm guessing this is due to downstream implementations wanting to pick
> > up the current release as base target (which can be done regardless,
> > but...).
> >
> > In theory we can hide flang by having to explicitly name it on the
> > build command, so merging now or later won't make massive practical
> > change.
> >
> > I personally don't like rushing things like that, but I'm not strongly
> > opposed to either, if everyone else is on board with the rush.
> >
> > cheers,
> > --renato
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200112/dd0f330f/attachment.html>