<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 12:30 AM Stephen Scalpone via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">About the choice of MLIR for Flang:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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].<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">At the 2019 dev meeting, Eric presented FIR in his talk[4] <i>
An MLIR Dialect for High-Level Optimization of Fortran</i>.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The flang MLIR dialect is documented in the FIR Language Reference [5]. It’s in an open pull request.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">- Steve<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">[1] <a href="https://github.com/flang-compiler/f18/blob/master/documentation/ControlFlowGraph.md" target="_blank">
https://github.com/flang-compiler/f18/blob/master/documentation/ControlFlowGraph.md</a><u></u><u></u></p>
<p class="MsoNormal">[2] <a href="https://github.com/flang-compiler/f18/blob/master/documentation/FortranIR.md" target="_blank">
https://github.com/flang-compiler/f18/blob/master/documentation/FortranIR.md</a><u></u><u></u></p>
<p class="MsoNormal">[3] <a href="https://github.com/flang-compiler/f18/commits/master/documentation/Investigating-FIR-as-an-MLIR-dialect.md" target="_blank">
https://github.com/flang-compiler/f18/commits/master/documentation/Investigating-FIR-as-an-MLIR-dialect.md</a><u></u><u></u></p>
<p class="MsoNormal">[4] <a href="https://youtu.be/ff3ngdvUang" target="_blank">https://youtu.be/ff3ngdvUang</a><u></u><u></u></p>
<p class="MsoNormal">[5] <a href="https://github.com/schweitzpgi/f18/blob/mono/documentation/FIRLangRef.md" target="_blank">
https://github.com/schweitzpgi/f18/blob/mono/documentation/FIRLangRef.md</a><u></u><u></u></p>
<p class="MsoNormal">[6] <a href="https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/edit?usp=sharing</a></p></div></div></blockquote><div><br></div><div>To add one more to the list: the llvm-dev proposal for MLIR also mentioned flang as a user: <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-September/134992.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-September/134992.html</a></div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Eric Christopher via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Reply-To: </b>Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>
<b>Date: </b>Sunday, January 12, 2020 at 10:51 PM<br>
<b>To: </b>Richard Barton <<a href="mailto:Richard.Barton@arm.com" target="_blank">Richard.Barton@arm.com</a>><br>
<b>Cc: </b>"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, Mike Edwards <<a href="mailto:medwards@llvm.org" target="_blank">medwards@llvm.org</a>><br>
<b>Subject: </b>Re: [llvm-dev] Flang landing in the monorepo - next Monday!<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<table border="1" cellpadding="0" style="background-color:rgb(255,235,156)">
<tbody>
<tr>
<td style="padding:0.75pt">
<p class="MsoNormal"><b><span style="font-size:7.5pt;font-family:Verdana,sans-serif;color:black">External email: Use caution opening links or attachments</span></b><span style="font-size:7.5pt;font-family:Verdana,sans-serif;color:black">
</span><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jan 9, 2020 at 4:28 AM Richard Barton via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12pt">Hi all<br>
<br>
Thanks for all the replies and engagement on this issue.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I think all these have been addressed (please correct me if you think otherwise)<br>
1. Audit trail/visibility of code review [Addressed by Peter - code has been reviewed [a] to F18 coding guidelines [b].<br>
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]<br>
3. Compatibility of license [Addressed by Steve, a recent update has made the licenses compatible [c]]<br>
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.]<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I think these are acknowledged right now and we are actively working on fixes:<br>
5. No use of lit in the regression tests [Arm is working on this]<br>
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] ]<br>
7. No use of LLVM utilities or standard data structures (Vector, etc.) [I think Pat and Eric have patches ready to go for this?]<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
I think these are only acknowledged, with the intention to remediate post merge, but no concrete plan or owner at this point:<br>
8. Simple deviations from the LLVM coding style<br>
a. Separating public headers into include/flang<br>
b. Syntactical things like braces on single line statements, comments on end of namespaces, etc.<br>
c. .cc file extensions rather than .cpp<br>
9. Bigger deviations from the LLVM coding style that are harder to fix<br>
a. Early exits and not using else after return, etc.<br>
10. Flang not supporting all the same C++ compilers as the rest of the project (even taking into account C++17 requirement) <u></u><u></u></p>
</blockquote>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12pt">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.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As well as this. A plan of action isn't just a "we'll get to this" but an actual plan :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12pt">Does anyone feel passionately that any of the above points need to be addressed in the code before we can merge?<br>
Does anyone feel there is anything missing from that list?<br>
<br>
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.<br>
<br>
What do people think to that proposal?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-eric<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Regards<br>
Rich<br>
<br>
[a] <a href="https://github.com/flang-compiler/f18/pulls" target="_blank">https://github.com/flang-compiler/f18/pulls</a><br>
[b] <a href="https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2Bstyle.md" target="_blank">
https://github.com/flang-compiler/f18/blob/master/documentation/C%2B%2Bstyle.md</a><br>
[c] <a href="https://github.com/flang-compiler/f18/commit/e06be2faa64a52471b3cfb2829dc05888236aa68" target="_blank">
https://github.com/flang-compiler/f18/commit/e06be2faa64a52471b3cfb2829dc05888236aa68</a><br>
[d] <a href="http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html" target="_blank">
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html</a><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Renato<br>
> Golin via llvm-dev<br>
> Sent: 9 January, 2020 10:02<br>
> To: Hans Wennborg <<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Mike Edwards <<a href="mailto:medwards@llvm.org" target="_blank">medwards@llvm.org</a>><br>
> Subject: Re: [llvm-dev] Flang landing in the monorepo - next Monday!<br>
> <br>
> On Thu, 9 Jan 2020 at 08:13, Hans Wennborg via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > > Why is it targeting pre-llvm10 branching? Are we expecting to ship<br>
> anything in LLVM 10? If so I would have expected it to land much much<br>
> earlier to be able to stabilize during the development phase long before the<br>
> branching point.<br>
> ><br>
> > I was wondering about this too. I'm not necessarily opposed, but<br>
> > wouldn't it make sense to target landing soon *after* the branch<br>
> > instead, to give it time to integrate, stabilize, and then ship in the<br>
> > next release?<br>
> <br>
> Usually, yes.<br>
> <br>
> I'm guessing this is due to downstream implementations wanting to pick<br>
> up the current release as base target (which can be done regardless,<br>
> but...).<br>
> <br>
> In theory we can hide flang by having to explicitly name it on the<br>
> build command, so merging now or later won't make massive practical<br>
> change.<br>
> <br>
> I personally don't like rushing things like that, but I'm not strongly<br>
> opposed to either, if everyone else is on board with the rush.<br>
> <br>
> cheers,<br>
> --renato<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
<div>
<hr>
</div>
<div>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. </div>
<div>
<hr>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>