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 <[email protected]> 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 <[email protected]> wrote: > >> Eric Christopher <[email protected]> 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
