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

[Greg Bedwell via llvm-dev]

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.

[image: Inline images 1]

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: Inline images 2]

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.

-Greg
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171019/c31991e6/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/c31991e6/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/c31991e6/attachment-0001.png>