- User Since
- Jul 7 2012, 2:54 PM (353 w, 6 d)
This looks right to me. Some suggestions on comment wording only.
Thu, Apr 18
Mostly questions around the AA manager preservation, see inline.
LGTM with comments below addressed. All pretty minor.
Wed, Apr 17
It looks like this is a completely new approach to attribute inference compared to the post-order function atters pass?
Generally really nice. Some suggestions on cleaning up comments and such in the tests.
FWIW, I'm not really a fan of this.
Mon, Apr 8
I think the approach here looks really good. Comments below.
Thu, Apr 4
Fri, Mar 29
While I think we should figure out how to test this, we shouldn't wait to land what seems like an important correctness fix on figuring out how to test. So mostly looking for a particular change below.
Wed, Mar 27
Fix up the CHECK lines in my new test case.
Tue, Mar 26
Thu, Mar 21
LGTM, thanks for all the plumbing here.
Just documentation tweaks....
Mar 20 2019
FWIW, I really like the direction and design here. Thanks so much for pushing all of this through, I think it is a really nice generalization of the caching done by BasicAA that lets us do more and more general things of this nature.
LGTM, really nice!
Mar 13 2019
Mar 8 2019
Mar 5 2019
Feb 28 2019
I do generally feel like it would be a useful and generically good direction to support the timing system having a pre-bound output stream so that it completely avoids the flag-based info output stream we currently use. It moves everything into a proper API instead of a flags based system that seems inherently hostile to more advanced users.
Feb 26 2019
Maybe update at least some of the tests using these targets to additionally run with the new pass manager explicitly enabled via flag?
Feb 20 2019
Feb 19 2019
LGTM (with a minor cleanup, but feel free to just submit w/ that if we're all agreeing about this direction).
I think we can consider tweaking the generic ones separately.
Based on the -dev discussion, update once the target machine differences are addressed by mimicing the way the legacy PM works, which will hopefully restrict this similarly to what Eli is suggesting as well...
Feb 18 2019
What about using /*/ at the ignore pattern? This allows top-level files, and makes only new top-level *directories* require an ignore update. To my mind, that seems a bit more narrowly scoped and might be a bit less surprising. Thoughts?
Feb 12 2019
Thanks for seeing through this .... very non-trivial effort! =D Also, as I'm sure you know by now, will need to watch the bots carefully. Sadly, some may fall over.
Feb 11 2019
Hey Marshall and Michael,
Feb 10 2019
Feb 8 2019
Feb 7 2019
Sorry this completely fell off my radar. It is back on my radar, and I'll try to get to it in the next day or two.
Feb 6 2019
This is looking really close. I think we should get some basic sanity checks w/ the kernel, and even if there is an obscure bug or two, land this and move to follow-up patches.
I think you may be able to do this in a slightly nicer way.
Feb 5 2019
Feb 4 2019
Just think we can poke the map a bit better here.
A few minor comments.