[PATCH] D12781: PGO IR-level instrumentation infrastructure

[Justin Bogner via llvm-commits]

Xinliang David Li <davidxl at google.com> writes:
> On Thu, Nov 19, 2015 at 7:22 PM, Sean Silva <chisophugis at gmail.com> wrote:
>> On Thu, Nov 19, 2015 at 6:59 PM, Xinliang David Li <davidxl at google.com>
>> wrote:
>>
>>> I thought about the size of the test case too. Initially I had the same
>>> concern, but in second look, it does not seem to be brittle -- because it
>>> just checks whether the key branches are properly annotated with the right
>>> profile count or not, or profile counter update instruction is inserted or
>>> not.
>>
>> It is brittle because it depends on checked in binary files that need to
>> be regenerated. For example, a person on Mac or Windows might have trouble
>> regenerating IR with `target triple = "x86_64-unknown-linux-gnu"`...
>
> This is the current common practice in testing PGO use and coverage. There
> are existing binary profile data checked in for both Instrument and Sample
> PGO.
>
> Also I am not sure what you mean by re-generating IR -- there is no need to
> re-generate IR.  Indexed profile data needs to be generated occasionally,
> but their format is system independent.  For the same program with the same
> training set, the indexed profile should be identical regardless whether
> the running system is 32bit or 64bit, LE or BE.

The only tests that use checked in binary profile data as inputs are
tests that are specifically about testing parsing the format. lit-style
tests that are meant to check how the profile is applied should use the
.proftext format, which is easier for a human to edit and understand as
well as being friendlier to version control.