[cfe-dev] [RFC] Clearing Clang AST before running backend optimizations/codegen to save memory

[David Blaikie via cfe-dev]

I think it'd be unfortunate if certain features don't work in this mode,
unless we understand why/are pretty sure that's a fairly fundamental
limitation. For instance, at Google we've got memory limitations (hence the
motivation for this work) and I think we created, or at least have some
interest in -Rpass - if -Rpass couldn't be composed with this feature, then
we'd make it harder to investigate performance issues (because -Rpass
wouldn't be available) in larger compiles that need this memory savings to
fit into the memory limits we have. I'd guess the issue is that -Rpass I
think traffics in Clang source locations. So it's possible the source
location infrastructure/data structures would have to be kept, even though
the AST/semantic pieces could be torn down. (unless that source location
stuff can refer into ASTs for differentiating template specializations, etc
- that'd be the tipping point for me in "OK, it may be worth the benefit to
make these incompatible, or reduce the quality of -Rpass diagnostics when
using this memory saving technique" - wonder if it's only the -Rpass
diagnostics, or other backend diagnostics that use that infrastructure)

Which is to say I'd be /slightly/ averse to adding this feature as a Clang
default or driver flag (& similarly averse to leaving it as a cc1
off-by-default flag indefinitely) without a pretty good answer to those
crashing/non-functioning tests.

(lower priority, but fairly nice-to-have would be some answer to the
cleaning up issues, -disable-free, etc - sort of weird that we'd have to
/disable-free/ to enable freeing things earlier... that seems pretty
suspicious)

but if those issues can be resolved

On Fri, Sep 17, 2021 at 2:30 PM Arthur Eubanks via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> We keep around the Clang AST when we do backend optimizations on the IR.
> This causes the peak memory usage to be more than necessary since (I
> believe) generally we don't need the Clang AST when running optimizations.
> This gives us more room to work with things like caching analyses, at least
> for frontend compilations.
>
> Measuring the effects of this when building LLVM's PassBuilder.cpp
> (longest LLVM file to compile), I measured a drop of peak memory usage
> (/usr/bin/time's max rss) from ~1.3-1.4G to ~1.0G.
>
> There are still a couple issues I haven't dug too deeply into yet, mostly
> to do with cleaning things up when freeing memory, so right now it's only
> enabled with -disable-free which works around those issues. Most clang
> tests pass with this patch; there are a couple things that crash (e.g.
> -Rpass, clang interpreter) where we can investigate further or just disable
> this feature.
>
> Prototype: https://reviews.llvm.org/D109781
> llvm-compile-time-tracker
> <https://llvm-compile-time-tracker.com/compare.php?from=167ff5280d7fcad731810d5d2bf10561ed2adacc&to=b08fcae3a02d5ebe58afd8f8658d798b62ff8eb7&stat=max-rss> memory
> metrics
>
> Any concerns with this?
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210917/36ae50d8/attachment.html>