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

[David Truby via flang-dev]

Hi everyone,

I just want to say that I'm actively looking in to this and
investigating possible solutions, I will post more information about
this on here when I have a better idea of what these solutions or any 
short term fixes might look like. If anyone else has any ideas please
let me know.

Thanks
David Truby

On Wed, 2019-11-20 at 17:19 +0100, Daniel Otero wrote:
> 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
> 
>