[llvm-dev] RFC: Switching to the new pass manager by default

[Chandler Carruth via llvm-dev]

On Thu, Oct 19, 2017 at 7:39 AM Greg Bedwell <gregbedwell at gmail.com> wrote:

> I looked at a few more of my earlier results in more detail.  In
> particular, from one of our test suites that produces some interesting
> compile-time and memory usage data for clang on Windows hosts.
>
> I did a comparison between "-O2 -g" and "-O2 -g
> -fexperimental-new-pass-manager".  As you'll see in the attached graphs, in
> general the suite contains some relatively small compilation units, mostly
> taking <5 seconds each to compile although there are a few larger ones in
> there too.  I'm using 64-bit clang.exe binary targeting the PS4 triple.
> I've limited the test harness to run a single process at a time.
> The first graph shows all of data points.  I'm plotting wall time along
> the X axis and PeakWorkingSetSize (see
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms684877%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
> ) along the Y axis.  As you can see there are a few interesting outliers
> with the new pass manager on both axes.  I'd like to do more investigation
> here and possibly raise some bugs if I can make shareable reproducers.
>

FWIW, the compile time regressions are a bit more interesting to me unless
the memory regression is unusually problematic for you or someone else. See
below...


>
> [image: extents.png]
>
> The next graph is the same data, but I've zoomed right in on the bottom
> left corner to see that cluster with the greatest concentration of points
> in more detail:
> [image: zoomed.png]
>
> The clusters of data points generally map quite well to each other here.
> There does seem to be a visible trend that the New PM is using more
> memory.  There's not enough data here to extrapolate any further (remember
> we're talking about <2 second compiles here), but it leaves me interested
> as to what the trend would be further out; in particular when applied to
> large LTO workloads where paging can become a big issue.  Essentially, is
> this a small, relatively constant overhead, or does it scale with overall
> memory usage?  I guess it's quite possible I'm seeing the effects of
> different inlining strategies.  This isn't necessarily a blocker either
> way, but it would be an interesting question to know the answer to.
>

This is definitely something I'm expecting, but something I want us to
watch closely.

The new PM caches analyses to avoid recomputing them. The good part of this
is reduced recomputation of analyses. The bad part is using more memory. So
the increase in memory *is* expected.

However, you might expect to see more reduction in compile time. Sadly,
these reductions are a bit slow for a few bad reasons:

1) The code generator isn't using the new pass manager yet. =[ So it throws
away cached results and recomputes them. This isn't any different from the
old pass manager, but still frustrating because we spent peak memory on
those results and didn't benefit from it.

2) A lot of the compile time goes to Clang and the code generator, hiding
any improvements.

So, provided the memory increases are "OK" (IE, not causing significant
resource starvation, or superlinear memory growth) I'm not too scared by
them. I'm more interested in checking why there are compile time
regressions.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/3546db87/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zoomed.png
Type: image/png
Size: 15899 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/3546db87/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extents.png
Type: image/png
Size: 13311 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/3546db87/attachment-0001.png>