[flang-dev] RFC: F18 build time memory requirements are too high

[Daniel Otero via flang-dev]

Hello everyone,

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.

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.

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.

We look forward to meeting you there.


On Mon, Nov 18, 2019 at 12:53 PM David Truby via flang-dev <
flang-dev at lists.llvm.org> wrote:

> Hi Steve,
>
> > Perhaps there are techniques that you can experiment with to speed up
> > compilation and reduce the peak memory usage and the amount of dead
> > code.  For example, external template declarations or C++20 Modules
> > come to mind.
> I played around with extern templates to try and reduce this issue,
> unfortunately they don't help here as we are using ".v" and ".t"
> members of (parts of) the parse tree in a lot of places, and to know
> the type of these requires instantiation. So although usually you could
> use extern template to force instantiation to occur in only one place,
> other files are still going to need to instantiate in this case.
>
> I haven't tried modules, but given that C++20 isn't published yet I
> feel a dependence on a feature from there would hinder our acceptence
> into the LLVM repo. I also suspect the same issue will arise as with
> precompiled headers, which I also tried; the issue being that these
> only solve the problem of having to parse the header multiple times, it
> won't help with instantiation as that still needs to do the same amount
> of work.
>
> > I don't know if std::variant is heavyweight or not, but perhaps f18
> > doesn't use all of its features. Chandler suggested a while back that
> > someone might write a lightweight llvm::variant that provides the
> > same type safety and features that f18 is using today.
> Unfortunately the problem isn't really with the implementation of
> std::variant but rather the template instantiation depth. Any
> implementation of something similar to variant would require an
> equivalent number of templates to be instantiated.
>
> It's possible we could improve template instantiation performance in
> clang (and gcc, as we get similar build time and memory usage results
> there). I suspect the low hanging fruit will have been picked already
> here though, as templates have been around in both compilers for some
> time.
>
> I saw Hal gave a talk at the LLVM meeting last month about template
> instantiation performance, perhaps he has some insight here?
>
> David Truby
>
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
>


-- 



*Daniel Otero** ~ Software engineer*
+34 881015556 <+34+881015556> | daniel.otero at appentra.com
 Edificio CITIC. Campus de Elviña s/n | www.appentra.com

-- 


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.


Appentra <http://www.appentra.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/flang-dev/attachments/20191120/0b043ee1/attachment-0001.html>