<div dir="ltr"><span id="gmail-docs-internal-guid-dedfa6e5-7fff-3060-597e-b0179e3de668"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Hello everyone,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">At Appentra, we have also been working with F18 and can only subscribe to Richard Barton's words. Compilation times and memory requirements are already posing a barrier to F18 adoption right now and we don't see any signs of improvement in the short or medium term. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Therefore, we believe that it is a priority as a community to re-evaluate the impact of this problem and try to find solutions as soon as possible. Do you see any value in asking for input about this in the LLVM-dev mailing list? Or folks at cfe-dev or cfe-users could give us some hints with the trace file that Richard has shared.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">We have discussed this and other issues with Hal Finkel and have agreed to present them in the bi-weekly technical call on December 2nd. We want to share our impressions on trying to use F18 for tooling to promote discussion and try to find paths for improvement. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">We look forward to meeting you there.</span></p></span><br class="gmail-Apple-interchange-newline"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2019 at 12:53 PM David Truby via flang-dev <<a href="mailto:flang-dev@lists.llvm.org">flang-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Steve,<br>
<br>
> Perhaps there are techniques that you can experiment with to speed up<br>
> compilation and reduce the peak memory usage and the amount of dead<br>
> code.  For example, external template declarations or C++20 Modules<br>
> come to mind.<br>
I played around with extern templates to try and reduce this issue,<br>
unfortunately they don't help here as we are using ".v" and ".t"<br>
members of (parts of) the parse tree in a lot of places, and to know<br>
the type of these requires instantiation. So although usually you could<br>
use extern template to force instantiation to occur in only one place,<br>
other files are still going to need to instantiate in this case.<br>
<br>
I haven't tried modules, but given that C++20 isn't published yet I<br>
feel a dependence on a feature from there would hinder our acceptence<br>
into the LLVM repo. I also suspect the same issue will arise as with<br>
precompiled headers, which I also tried; the issue being that these<br>
only solve the problem of having to parse the header multiple times, it<br>
won't help with instantiation as that still needs to do the same amount<br>
of work.<br>
<br>
> I don't know if std::variant is heavyweight or not, but perhaps f18<br>
> doesn't use all of its features. Chandler suggested a while back that<br>
> someone might write a lightweight llvm::variant that provides the<br>
> same type safety and features that f18 is using today.<br>
Unfortunately the problem isn't really with the implementation of<br>
std::variant but rather the template instantiation depth. Any<br>
implementation of something similar to variant would require an<br>
equivalent number of templates to be instantiated.<br>
<br>
It's possible we could improve template instantiation performance in<br>
clang (and gcc, as we get similar build time and memory usage results<br>
there). I suspect the low hanging fruit will have been picked already<br>
here though, as templates have been around in both compilers for some<br>
time.<br>
<br>
I saw Hal gave a talk at the LLVM meeting last month about template<br>
instantiation performance, perhaps he has some insight here?<br>
<br>
David Truby<br>
<br>
_______________________________________________<br>
flang-dev mailing list<br>
<a href="mailto:flang-dev@lists.llvm.org" target="_blank">flang-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><table border="0" cellspacing="0" cellpadding="0" width="470" style="color:rgb(0,0,0);font-family:Helvetica,Arial,sans-serif;font-size:12.8px;width:470px"><tbody><tr valign="top"><td style="border-right:1px solid rgb(0,0,0);padding-right:10px;width:10px;max-width:120px"><font size="2"><img src="https://s3.amazonaws.com/ucwebapp.wisestamp.com/913e9776-9f3a-46f5-9ff0-a93fa485d77d/appentra01.crop_806x719_221,41.preview.format_png.resize_200x.png" width="96" height="84"></font></td><td style="font-family:Arial;color:rgb(100,100,100);padding-left:10px"><div style="text-transform:capitalize"><table border="0" width="470" style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:medium;text-transform:none;width:470px;background-color:rgb(254,254,254)"><tbody><tr valign="top"><td style="width:10px;vertical-align:top;white-space:nowrap"><span style="font-size:small"><font face="trebuchet ms, sans-serif"><br><br></font></span></td><td style="text-align:initial"><span style="text-align:initial;font-size:13px"><font color="#444444" face="trebuchet ms, sans-serif"><b><br>Daniel Otero</b></font><i style="color:rgb(128,128,128)"> ~ Software engineer</i></span><span style="font-size:13px"><strong><font color="#444444"><br></font></strong></span><font face="arial narrow, sans-serif"><span style="font-size:13px"><span style="color:rgb(128,128,128)"><a href="tel:+34+881015556" style="color:rgb(128,128,128);outline:none;text-decoration:none" target="_blank">+34 881015556</a> </span><span style="color:rgb(128,128,128)"><span style="color:rgb(0,0,0)">| </span></span></span></font><span style="color:rgb(102,102,102);font-family:"arial narrow",sans-serif;font-size:13px"><a href="mailto:daniel.otero@appentra.com" style="color:rgb(17,85,204)" target="_blank">daniel.otero@appentra.com</a></span><span style="font-family:"arial narrow",sans-serif;text-align:initial;font-size:13px"><span style="color:rgb(128,128,128)"><span style="color:rgb(0,0,0)"> <br></span> </span></span><span style="color:rgb(128,128,128);font-family:"arial narrow",sans-serif;font-size:13px">Edificio CITIC. Campus de Elviña s/n</span><span style="text-align:initial;font-family:"arial narrow",sans-serif;font-size:13px"> </span><span style="text-align:initial;font-family:"arial narrow",sans-serif;font-size:13px">| <a href="http://www.appentra.com/" style="color:rgb(128,128,128);outline:none" target="_blank">www.appentra.com</a></span></td></tr></tbody></table></div></td></tr></tbody></table></div></div></div></div>

<br>
<p style="background-color:rgb(255,255,255)"><span style="color:rgb(34,34,34);font-family:arial,sans-serif"><font size="1">This message and its attachments contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Company Appentra Solutions S.L., Ed. de Servicios Centrales de Investigación, Campus de Elviña S/N, E-15071, A Coruña, Spain.</font></span></p><p style="font-family:arial,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255)"><font size="1"><font color="#1155cc"><a href="http://www.appentra.com" target="_blank">Appentra</a></font> agrees to abide by the stipulations of Organic Law 15/1999 of 13 December on the Protection of Personal Data (LOPD), in the event that the user furnish personal data, collection thereof be made only with your consent , that are subsequently incorporated into legal files which would be responsible Appentra, to apply to the related activity. The user may exercise their rights of access, rectification, cancellation and opposition by writing, enclosing a photocopy of your ID, APPENTRA, Data Protection Department, Ed. Servicios Centrales de Investigación, Campus de Elviña S/N, 15071, A Coruña, Spain. Also, data of the user could be used by the company to send you information of interest.</font></p>