[PATCH] Initial instrumentation based PGO implementation

Eric Christopher echristo at gmail.com
Sun Dec 29 20:56:09 PST 2013


Must have slipped off of my radar - especially with the holidays.
Thanks for the ping.

-eric

On Sun, Dec 29, 2013 at 8:49 PM, Bob Wilson <bob.wilson at apple.com> wrote:
> Eric,
>
> Thanks for your careful review of this.  Your comments about the testing strategy have been especially helpful. This is an initial patch that is going to be revised extensively before the feature is finished. There are a lot of incremental changes that need to happen, and at least for myself, I have been unable to contribute any of those changes while we wait to get this initial patch committed. It has now been almost a month since Justin first submitted this patch (Dec. 1). I have carefully reviewed it twice, and John (the code owner) has also reviewed it. Can you please give an OK to let Justin commit this patch?
>
> On Dec 19, 2013, at 12:37 AM, Justin Bogner <mail at justinbogner.com> wrote:
>
>> Eric Christopher <echristo at gmail.com> writes:
>>> I don't think we should have any executable tests in the front end at all. I
>>> think the easiest way here would be to check in an input file alongside the
>>> test file similar to how the Object tests work (an Inputs directory).
>>>
>>> Thoughts?
>>
>> I'm a bit leery of input files, especially since the file format for the
>> PGO stuff is explicitly in flux here. That said, writing tests the way
>> you suggest has a number of advantages and tests that only sometimes run
>> are clearly inferior.
>>
>> So I went ahead and ripped out the profile-generate part, added an input
>> file for the profile-use part, and even added a test that we ignore
>> bogus data, which was impossible with the previous approach.
>>
>> Doing so pointed out the problem with this change. The tests I had were
>> testing two things: generating profile data, and using it. Using an
>> input file was only the latter. That's lame, so I've added a second run
>> line that spits out IR and checks that we're incrementing the
>> appropriate counters for the various constructs.
>>
>> In short, this makes the tests *way* better. They're twice as
>> complicated, but they're testing twice as much stuff. Check it out.
>>
>> <0002-CodeGen-Initial-instrumentation-based-PGO-implementa.patch>_______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>




More information about the cfe-commits mailing list