[PATCH] [LPM] A targeted but somewhat horrible fix to the legacy pass manager's querying of the pass registry.

[Owen Anderson]

Hi Chandler,

In my measurements, this captures about half of the regression, i.e. the regression goes from ~20% to ~10%.  While the reader/writer locks are gone from the profile, several other PassManager related pieces of code have jumped up to take their place:



—Owen


> On Jan 27, 2015, at 3:42 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> Hi resistor,
> 
> The pass manager relies on the static registry of PassInfo objects to
> perform all manner of its functionality. I don't understand why it does
> much of this. My very vague understanding is that this registry is
> touched both during static initialization *and* while each pass is being
> constructed. As a consequence it is hard to make accessing it not
> require a acquiring some lock. This lock ends up in the hot path of
> setting up, tearing down, and invaliditing analyses in the legacy pass
> manager.
> 
> On most systems you can observe this as a non-trivial % of the time
> spent in 'ninja check-llvm'. However, I haven't really seen it be more
> than 1% in extreme cases of compiling more real-world software,
> including LTO.
> 
> Unfortunately, some of the GPU JITs are seeing this taking essentially
> all of their time because they have very small IR running through
> a small pass pipeline very many times (at least, this is the vague
> understanding I have of it).
> 
> This patch tries to minimize the cost of looking up PassInfo objects by
> leveraging the fact that the objects themselves are immutable and they
> are allocated separately on the heap and so don't have their address
> change. It also requires a change I made the last time I tried to debug
> this problem which removed the ability to de-register a pass from the
> registry. This patch creates a single access path to these objects
> inside the PMTopLevelManager which memoizes the result of querying the
> registry. This is somewhat gross as I don't really know if
> PMTopLevelManager is the *right* place to put it, and I dislike using
> a mutable member to memoize things, but it seems to work.
> 
> For long-lived pass managers this should completely eliminate
> the cost of acquiring locks to look into the pass registry once the
> memoized cache is warm. For 'ninja check' I measured about 10% reduction
> in CPU time, and about a 1% reduction in total time on a machine with 32
> hardware threads. For normal compilation, I don't know how much this
> will help, sadly. We will still pay the cost while we populate the
> memoized cache. I don't think it will hurt though, and for LTO or
> compiles with many small functions it should still be a win.
> 
> http://reviews.llvm.org/D7213
> 
> Files:
>  include/llvm/IR/LegacyPassManagers.h
>  lib/IR/LegacyPassManager.cpp
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> <D7213.18862.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150127/b74b2285/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ThreadProfile2.png
Type: image/png
Size: 82453 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150127/b74b2285/attachment.png>