<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.gmail-m-1195941680496066381apple-converted-space
{mso-style-name:gmail-m_-1195941680496066381apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Reply inline<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Chandler Carruth <chandlerc@gmail.com><br>
<b>Date: </b>Monday, February 25, 2019 at 2:46 PM<br>
<b>To: </b>Stephen Scalpone <sscalpone@nvidia.com><br>
<b>Cc: </b>"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [llvm-dev] RFC for f18+runtimes in LLVM<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
<span style="color:black">* The current f18 code will be committed to the new LLVM subproject. <span class="gmail-m-1195941680496066381apple-converted-space"> </span>The f18 code is a set of libraries that implements the Fortran compiler.</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Awesome. This is an important aspect of the design of LLVM projects IMO -> they build their functionality primarily as re-usable libraries, and then expose that in useful command line utilities.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
<span style="color:black">The f18 compiler source code complies with most of LLVM's coding guidelines; however, the code uses several C++17 features. We've documented our use of C++17 here:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> <span class="gmail-m-1195941680496066381apple-converted-space"> </span></span><a href="https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md" target="_blank"><span style="color:#954F72">https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md</span></a><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black">In particular, the parse tree and the lowered forms of expressions and variables are defined in terms of C++17<span class="gmail-m-1195941680496066381apple-converted-space"> </span>std::variant. Most of the compiler uses C++17<span class="gmail-m-1195941680496066381apple-converted-space"> </span>std::visit
to walk these data structures.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black">It’s possible to reimplement the most important functionality of<span class="gmail-m-1195941680496066381apple-converted-space"> </span>std:variant<span class="gmail-m-1195941680496066381apple-converted-space"> </span>as a subset class,
say<span class="gmail-m-1195941680496066381apple-converted-space"> </span>llvm:variant; however, variant gets its power from the C++17 features generic lambdas and parameter pack expansion on “using”. <span class="gmail-m-1195941680496066381apple-converted-space"> </span>Without
these C++17 features, use of variant would be impractical.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black">Our thinking when we started was that llvm would adopt C++17 before mid-2020, which lines up with our projected completion date. If we were to adopt C++11 or C++14, we would likely create substitutes for these classes, certainly at
a cost of calendar time and perhaps type safety and notational convenience. One of our principles is to take advantage of the standard library as much as possible, so casual readers will better understand our code and so we avoid the time and bugs associated
with writing class libraries.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;font-variant-caps:normal;text-align:start;word-spacing:0px">
<span style="color:black">Our request would be to get a waiver for the C++11 requirement based on the fact that we're skating to where the puck will be. In the meantime, because F18 only exists as a stand-alone program, early adopters would still have a useful
parser and analyzer for Fortran.</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Hold on, either it is a collection of libraries or it is a stand-alone program. It can't really be both?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I misspoke.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black">f18 comprises several libraries, as well as a simple executable compiler driver program for testing purposes.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">The libraries correspond to the subdirectories in lib/. They can be built as shared or static binary libraries.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">lib/common contains utilities and Fortran language representations used throughout the project.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">lib/parser contains the Fortran preprocessor and source normalization code, source provenance tracking, parser combinator sublibrary, Fortran and OpenMP grammars, parse tree definitions, an “unparser”, and an error
message handling sublibrary. It depends only on lib/common.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">lib/evaluate contains a strongly typed representation for Fortran expressions, constants, and constant folding. It uses the parser’s error message facility when folding but is otherwise fairly independent code.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">lib/semantics contains the symbol table, declaration processing, name resolution, expression typing, and constraint checking. It depends on everything above. It remains under active development.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">lib/FIR contains the beginnings of the representation for executable code and its translation to LLVM IR. It depends on everything above as well as on LLVM libraries.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Both the parser and the semantic analysis libraries comprise definitions of “top level” objects that compose and orchestrate the contents of their respective libraries into fairly narrow parameterized interfaces
that hide much of their implementations, so that one may easily parse a Fortran source file within a context of macro definitions and enabled/disabled language extensions and get back a parse tree and error message collection with minimal fuss. The temporary
scaffolding driver in tools/f18 drives and connects these top-level interfaces for testing purposes.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">There will of course also be a large Fortran runtime support library for use by compiled code.</span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Generally, I think the idea that diverging from the rest of the project here is low-cost for a subproject isn't supported by experience with other projects.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Notably, it has a strong tendancy to create tension. You want some ADT or support library in LLVM to work well with your C++17 code. But it is C++11. Every time this has been done in the past, the result has been
that generically useful tools and libraries get added to the subproject rather than to LLVM as a whole.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">So FWIW, I'd be really opposed to this. Instead, I think that F18 should have rich libraries, and develop them exactly the same way as the rest of LLVM.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">We're getting close to switching to C++14, so maybe due to timing, you could merge F18 when that happens?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Ultimately, I think you either need to raise the LLVM base language version or lower the F18 one so that they match when merged IMO. Anything else I think will hamper integration with the larger project.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As for the day-to-day usage of C++17, other replies suggest that building f18 should be disabled by default or that f18 builds detect that the host compiler doesn’t support C++17 and (silently) refuse to build. (I haven’t looked at whether
this is possible or not.) Either of these options allows build-bots and older projects to continue as is without changing for the sake of f18 & C++17.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nearly all of the support routines we developed so far are very specific to Fortran. There are some idea around constant folding and reuse of the runtime library for intrinsic folding that we’re developing; perhaps these ideas will be
generally useful in the future.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">- Steve<o:p></o:p></p>
</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>
</body>
</html>