Automatic PGO - Initial implementation (1/N)

[Diego Novillo]

On Tue, Sep 24, 2013 at 10:07 AM, Diego Novillo <dnovillo at google.com> wrote:
> This adds two options: -auto-profile and -auto-profile-file. The new
> option causes the compiler to read a profile file and emit IR
> metadata reflecting that profile.
>
> The profile file is assumed to have been generated by an external
> profile source. The profile information is converted into IR metadata,
> which is later used by the analysis routines to estimate block
> frequencies, edge weights and other related data.
>
> External profile information files have no fixed format, each profiler
> is free to define its own. This includes both the on-disk representation
> of the profile and the kind of profile information stored in the file.
> A common kind of profile is based on sampling (e.g., perf), which
> essentially counts how many times each line of the program has been
> executed during the run.
>
> The only requirements is that each profiler must provide a way to
> load its own profile format into internal data structures and
> then a method to convert that data into IR annotations.
>
> The AutoProfile pass is organized as a scalar transformation. On
> startup, it reads the file given in -auto-profile-file to determine what
> kind of profile it contains.  This file is assumed to contain profile
> information for the whole application. The profile data in the file is
> read and incorporated into the internal state of the corresponding
> profiler.
>
> To facilitate testing, I've organized the profilers to support two file
> formats: text and native. The native format is whatever on-disk
> representation the profiler wants to support, I think this will mostly
> be bitcode files, but it could be anything the profiler wants to
> support. To do this, every profiler must implement the
> AutoProfiler::loadNative() function.
>
> The text format is mostly meant for debugging. Records are separated by
> newlines, but each profiler is free to interpret records as it sees fit.
> Profilers must implement the AutoProfiler::loadText() function.
>
> Finally, the pass will call AutoProfiler::emitAnnotations() for each
> function in the current translation unit. This function needs to
> translate the loaded profile into IR metadata, which the analyzer will
> later be able to use.
>
> This patch implements the first steps towards the above design. I've
> implemented a sample-based flat profiler. The format of the profile is
> fairly simplistic. Each sampled function contains a list of relative
> line locations (from the start of the function) together with a count
> representing how many samples were collected at that line during
> execution. I generate this profile using perf and a separate converter
> tool.
>
> Currently, I have only implemented a text format for these profiles. I
> am interested in initial feedback to the whole approach before I send
> the other parts of the implementation for review.
>
> This patch implements:
>
> - The AutoProfile pass.
> - The base AutoProfiler class with the core interface.
> - A SampleBasedProfiler using the above interface. The profiler
>   generates metadata autoprofile.samples on every IR instruction that
>   matches the profiles.
> - A text loader class to assist the implementation of
>   AutoProfiler::loadText().
>
> Caveats and questions:
>
> 1- I am almost certainly using the wrong APIs or using the right
>    APIs in unorthodox ways. Please point me to better
>    alternatives.
>
> 2- I was surprised to learn that line number information is not
>    transferred into the IR unless we are emitting debug
>    information. For sample-based profiling, I'm going to need
>    line number information generated by the front-end
>    independently of debug info. Eric, is that possible?
>
> 3- I have not included in this patch changes to the analyzer. I
>    want to keep it focused to the profile loading and IR
>    annotation. In the analyzer, we will have propagation of
>    attributes and other fixes (e.g., from the samples it is
>    possible to have instructions on the same basic block
>    registered with differing number of samples). I also have not
>    included changes to code motion to get rid of the autoprofile
>    information.
>
> 4- I need to add test cases.
>
> Mainly, I'm interested in making sure that this direction is
> generally useful. I haven't given a lot of thought to other types
> of profiling, but I'm certain any kind of tracing or other
> execution frequency profiles can be adapted. Things like value
> profiling may be a bit more involved, but mostly because I'm not
> sure how the type and symbols are tracked in LLVM.
>
> Thanks.  Diego.

I've updated the patch to add a basic unit test.  I have more that
exercise the analysis changes I have in my local tree (patch to
follow).

The attached patch is identical to the one I sent a few weeks ago,
with the added unit test.


Thanks.  Diego.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-AutoProfile-pass.-Initial-setup.patch
Type: application/octet-stream
Size: 22452 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131008/db9ab768/attachment.obj>