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

[David Truby via flang-dev]

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