[PATCH] Initial instrumentation based PGO implementation
echristo at gmail.com
Sun Jan 5 18:34:13 PST 2014
Will get to this tomorrow.
On Jan 5, 2014 6:33 PM, "Justin Bogner" <mail at justinbogner.com> wrote:
> Eric Christopher <echristo at gmail.com> writes:
> > 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>
> >> 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>
> >>> 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
> >>> 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
> >>> are clearly inferior.
> >>> So I went ahead and ripped out the profile-generate part, added an
> >>> 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.
> >>> cfe-commits mailing list
> >>> cfe-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits