[llvm-dev] RFC: Pass to prune redundant profiling instrumentation

[Justin Bogner via llvm-dev]

Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> writes:
> On Thu, Mar 10, 2016 at 7:21 PM, Vedant Kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I'd like to add a new pass to LLVM which removes redundant profile counter
>> updates. The goal is to speed up code coverage testing and profile
>> generation
>> for PGO.
>>
>
> We may want to have a focused discussion about this goal, rather than a
> particular suggestion. There are a lot of things we can do. Off the top of
> my head, some are:
>
> 1. add some sort of alias annotation (such as an independent TBAA root
> node) to all the counter increment memory instructions to tell the
> optimizer they don't interfere with the usual loads and stores.
>
> 2. communicate to the optimizer that counters can be registerized. In a
> loop like:
> for (int i = 0; i < N; i++) {
>   if (foo())
>     bar();
>   else
>     baz();
> }
> we perform O(N) counter increments (i.e. load, increment, store) last I
> checked. However, if the counters are in registers, then we only perform
> O(1) memory operations. This can dramatically reduce the pressure on the
> CPU's load/store units and also relieve cross-core cache line ping-pong
> when two cores are executing the same code. Note that the latter benefit is
> attained even if we ultimately end up spilling the counters due to
> increased register pressure.
>
> I actually don't know what is preventing the usual optimization pipeline
> from getting 2 right.

Yes, we definitely want to teach optimizations to be clever about
instrumentation counters. This kind of thing should help both the FE and
IR based instrumentation.

I think it's somewhat orthogonal to Vedant's approach here though - even
if we can hoist increments out of loops or do the work in registers some
of the time, reducing counts that are known to be identical to one
memory location should still bring a fair bit of value.