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

[Mehdi AMINI via llvm-dev]

On Mon, Jan 13, 2020 at 12:30 AM Stephen Scalpone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> About the choice of MLIR for Flang:
>
>
>
> Early on, the f18 project put up a doc [1]  describing, at a high level,
> the requirements for an intermediate representation of a program’s
> executable part.  This document was followed by a design document for a
> Fortran IR, FIR [2].
>
>
>
> When MLIR was announced in April 2019, we noted the similarity between
> MLIR and our in-flight implementation of FIR, in particular a good match
> between the semantics of Fortran and the semantics of MLIR.  Eric Schweitz
> started an investigation of FIR as an MLIR dialect.  The results [3] were
> published in June 2019. The document has some analysis, but mostly shows
> how FIR could be implemented as an MLIR dialect.
>
>
>
> The investigation and choice of MLIR was discussed on the July 3 flang
> technical call [6].  (This call is bi-weekly, alternating with a flang
> project management call.)   There was a lot of excitement about MLIR and no
> one raised any technical objections at the time.  There were concerns, now
> moot, about how flang would interact with MLIR if MLIR was not an llvm
> subproject.
>
>
>
> At the 2019 dev meeting, Eric presented FIR in his talk[4] * An MLIR
> Dialect for High-Level Optimization of Fortran*.
>
>
>
> The flang MLIR dialect is documented in the FIR Language Reference [5].
> It’s in an open pull request.
>
>
>
> - Steve
>
>
>
> [1]
> https://github.com/flang-compiler/f18/blob/master/documentation/ControlFlowGraph.md
>
> [2]
> https://github.com/flang-compiler/f18/blob/master/documentation/FortranIR.md
>
> [3]
> https://github.com/flang-compiler/f18/commits/master/documentation/Investigating-FIR-as-an-MLIR-dialect.md
>
> [4] https://youtu.be/ff3ngdvUang
>
> [5]
> https://github.com/schweitzpgi/f18/blob/mono/documentation/FIRLangRef.md
>
> [6]
> https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/edit?usp=sharing
>

To add one more to the list: the llvm-dev proposal for MLIR also mentioned
flang as a user:
http://lists.llvm.org/pipermail/llvm-dev/2019-September/134992.html

On the MLIR side we're very excited by the flang use-case: helping to plug
arbitrary frontends on top of LLVM is an important aspect of MLIR and we
expect that flang will contribute to drive the development of MLIR as a
successful framework to achieve this.

Cheers,

-- 
Mehdi



>
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Eric
> Christopher via llvm-dev <llvm-dev at lists.llvm.org>
> *Reply-To: *Eric Christopher <echristo at gmail.com>
> *Date: *Sunday, January 12, 2020 at 10:51 PM
> *To: *Richard Barton <Richard.Barton at arm.com>
> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Mike Edwards <
> medwards at llvm.org>
> *Subject: *Re: [llvm-dev] Flang landing in the monorepo - next Monday!
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
>
>
>
>
> 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
>
> ------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> ------------------------------
> _______________________________________________
> 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/20200113/5a9beb5b/attachment-0001.html>