[cfe-dev] RFC: prototype of clang-scan-deps, faster dependency scanning tool for explicit modules and clangd

[Sam McCall via cfe-dev]

Hi Alex,

Sorry for the late reply here.
This seems like a very useful tool, that (at least in the current
implementation) comes at the cost of adding complexity to various layers of
clang.
Is the 10x speedup vs invoking the preprocessor programmatically? That
indeed seems like a lot. What is the performance target (e.g. is that speed
up just nice-to-have, is it sufficient, are further wins needed?). Did you
measure what running the preprocessor directly buys you? (Your prototype
runs Eonly by invoking clang in a subshell through the driver).

The design seems to leave headroom in a couple of dimensions:
 - performance: avoiding reprocessing files (in any capacity) could in
principle be a pretty big win, as the average number of transitive
includers scales somewhat with codebase size
 - complexity: the full power of the lexer/preprocessor system is not
needed for the vast majority of include-scanning cases. (This also impacts
performance).

How important is it that scanning is precise w.r.t preprocessor state (e.g.
#ifdef'd out headers are not considered dependencies), and accurate in edge
cases (#include SOME_MACRO)? Do you have any measurements on how often
these scenarios occur?

> We also would like to integrate this service into Clangd as part of our
migration to Clangd to help us determine a good compilation command for a
header file from a set of known compilation invocations.
We introduced a heuristic approach to this (simply examining filenames to
find a decent match) into Tooling as a CompilationDatabase, it would be
great if it's possible to do something similar with dep scanning so it's
reusable by other tools and layering is preserved.

On Wed, Oct 17, 2018 at 3:54 AM Alex L via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> Hi,
>
>
> Bruno (CCed), Duncan (CCed) and I have been exploring if we can migrate
> some of our clients to explicit modules. As part of this work Duncan and I
> developed a new prototype dependency scanning service tool
> (clang-scan-deps) that computes the set of file dependencies for a
> particular compiler invocation using some optimizations that are outlined
> below. This tool makes the non-modular dependency scanning up to 10 times
> faster for particular workloads (e.g. llc target, 1542 C++ files) on one of
> our machines, when compared to parallel invocations of clang with -Eonly.
> We are still in the early stages of proper modules support, but our initial
> crude prototype can get up to 4x when run on the first 1000 files from
> clang’s compilation database for a build of LLVM with modules turned on.
>
>
> We still run the full Clang preprocessor. Here’s what we do to reduce its
> workload:
>
>    - Minimize sources by stripping away unused tokens. We keep only the
>    interesting PP directives (#define, #if, #include, etc.), i.e. those that
>    might impact the set of dependencies.
>    - Assume the filesystem is immutable for one run of the service, and
>    cache the files and their minimized contents in memory in a global cache.
>    - Skip over excluded preprocessor ranges by bumping up the buffer
>    pointer in the lexer instead of lexing the skipped tokens.
>
>
> We intend to upstream this service in the upcoming months. We also would
> like to integrate this service into Clangd as part of our migration to
> Clangd to help us determine a good compilation command for a header file
> from a set of known compilation invocations.
>
>
> I posted a very rough WIP patch on Phabricator (
> https://reviews.llvm.org/D53354). It’s based on LLVM checkout r343343.
> Please take a look if you’re interested.
>
> Duncan, Bruno and I will be at the LLVM dev meeting. We are interested in
> discussing this prototype and collecting feedback from anyone who might be
> interested in this work.
>
>
> Thanks,
>
> Alex
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://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/20181113/a0860ac5/attachment.html>