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

On Thu, Jan 9, 2020 at 4:19 AM Mehdi AMINI via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <llvm-dev at
lists.llvm.org> 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.
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?

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

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

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

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?

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