- User Since
- Jul 7 2012, 2:54 PM (429 w, 3 d)
Sat, Sep 19
Good to confirm with Dave of course, but this looks pretty great to me, and thanks so much!
FWIW, I would like to see *something* like this (both in the release and on trunk) but not sure this is actually the patch we want... Clang typically uses FIXME comments, and doesn't leave commented out code...
Wed, Sep 16
Wed, Sep 9
(Continuing the discussion here as I'm not really aware of a better place... feel free to point to a different thread if better... I don't actively follow llvm-dev at this point though, sorry if I've missed a post there.)
(And to be clear, IMO we should revert this patch while the discussion concludes as this is breaking real code.)
Regarding access to volatile memory...
Mon, Sep 7
Somewhat minor post-commit thought, but we now have both a library FileCheck and an executable binary FileCheck (not to mention the existing confusion of having two FileCheck.cpp files).
May 29 2020
Cool, thanks and LGTM!
May 24 2020
May 13 2020
LGTM!! Thanks for tracking down this surprising fix to the PR!
May 12 2020
LGTM, but one of these I think should be addressed here.
LGTM other than two nits here, this is really awesome!
May 5 2020
As much as I'm not thrilled about the duplication, the number of comments I have below about the exact O1 pipeline sure make it seem valuable. Unsure how you feel about addressing these here, later, etc.
Wooot about finally having a test case! (Sorry for nit picking it a bit ....)
LGTM with the addition of skipping debug info as Eli suggests.
May 4 2020
Might also be good to explain a bit of *how* this fixes the PR to the commit log (or bug) for posterity. It seemed to surprise both of us that this was the fix when talking through the code, I suspect a future reader may benefit from having a log of what went on here.
Apr 21 2020
Really like the approach now. Pretty minor code nits below only. =D
Apr 3 2020
Feb 22 2020
Feb 21 2020
Dec 26 2019
Can we add an LLVM test w/ the metadata so that we have an entirely LLVM test flow that ensures the pass builder DTRT?
Dec 16 2019
Just wanted to say thanks for the performance data! I know it was hard to get, but it is really, really useful to help folks evaluate these kinds of changes with actual data around the options available.
Dec 10 2019
I just want to mention here, that my comment on the original patch still stands and really needs to be addressed:
Dec 3 2019
I'm seeing lots of updates to fix bugs, but no movement for many days on both my meta comments and (in some ways more importantly) James's meta comments. (And thanks Philip for chiming in too!)
Nov 30 2019
Nov 24 2019
Minor nits around redundant predicates for SROA. With thouse fixed, LGTM.
(Just a reminder that we need to have both performance and code size numbers for this patch. And given that there are a few options, may need a few examples.)
Nov 13 2019
Thanks for sending this out!
Oct 23 2019
A few minor further tweaks.
More fixes from Manuel.
Address feedback from Manuel.
Oct 17 2019
Generally very happy with this. Would like Eric to check this as well to think about the C API and other things that we maybe should be doing while unbuilding this....
Oct 13 2019
FWIW, the adjustments I'm suggesting around tightening the logic can easily be in a follow-up patch if you like. I think generally the code LGTM and I'd just like us to pin down exactly what changes we expect to happen w/ the handles as much as possible to avoid subtle latent bugs creeping in and never getting noticed.
Oct 11 2019
(Tried to get this out last weekend, but was blocked by the Phab down time... Sorry about that ...)
Oct 5 2019
Adding Alina so she is aware of the change and can comment if she spots anything I'm missing...
Sep 11 2019
Sep 7 2019
LGTM to fix folks broken by this.
Sep 3 2019
This also makes sense to me why it would OOM. I suspect we're building a massive list, and at best we get lucky and they get de-duped later. At worst, this is actually fixing a serious functionality problem. We had the same thing w/ normal ASan before too. Since this pass doesn't need to be a function pass anyways, this seems totally fine. Thanks for tracking it down.
This idea isn't fundamentally flawed, its a good idea and something we've discussed many times.
Aug 28 2019
FWIW, LGTM. Thanks for all the work figuring out the right way to manage this at each step, and seeing it through, I think this is really great.
Aug 27 2019
Aug 20 2019
Thanks to Joerg for some useful discussion on IRC -- there was a concern I hadn't thought about that is exactly right: we somewhat want this pass to minimally disrupt things but also to be reasonably self contained.
Some nits below. LGTM with those fixed!
Aug 16 2019
This seems .... somewhat unfortunate. Adding Chris Bieneman to see if this is really the right thing to do or there are any other alternatives.
Aug 14 2019
As we discussed in person, we should refactor this so that when we enable MemorySSA we actually check the the loop passes in question mnanage to preserve it.
Also LGTM for cherrypick to the release branch.
Aug 13 2019
This approach is broken for another reason, which also motivated the LoopSink approach David mentioned.
This too LGTM, and again, thanks for driving this all the way through.
We should specifically call this out in release notes as well (before we forget) as a bunch of downstream people will discover it in LLVM 10.
Aug 12 2019
Aug 5 2019
One high level point that is at least worth clarifying, and maybe others will want to suggest a different approach:
Aug 3 2019
Generally, I do like the approach. Two high level comments:
Aug 1 2019
LGTM! Thanks for fixing this nasty bug (and sorry I wrote it).
LGTM with two nits addressed, thanks!
Jul 31 2019
Jul 11 2019
Just to make sure we're on the same page (and sorry I didn't jump in sooner)...
Sorry for the delay here.
LGTM, thanks so much for sticking through this, I know it was ... nontrivial!
Jul 2 2019
Pointing out the (serious) bug in this change below.
Jul 1 2019
The used thing still seems like there is an underlynig bug here. See below.
Since this review is ongoing, please revert the original patch to unblock people. There is no harm in reverting and landing with the fix once it is ready. =]
Jun 28 2019
Ok, now I've made a full pass through this. Mostly I think the first thing to do is tighten up the design around the core run function template and how reducers work with it. Documenting that design in detail will be really helpful I think.
(Also, really sorry, I mashed send button too soon, I'm still going through the code. Feel free to start on anything i posted, but sorry for the very random subset of comments)
I'd suggest enhancing the main description to include an overview of the code structure and organization to help reviewers follow the implementation design here. Think of it like a mini design doc for the *implementation* itself.
Jun 24 2019
Personally, I'd suggest the name llvm-reduce for the tool.
Jun 21 2019
FWIW, I think we can wait for a bug to be filed or report come in with some functional test case before we change any behavior here.
Jun 20 2019
Eh, this seems close enough now. I'd like a better approach for the x86 builtins, but no idea what it will end up being.
See inline comment, but I think we should just drop the testing of the function attribute bit here rather than adjusting the pipeline.
(Will likely need more eyes than just mine -- RPATH is mostly a mystery to me...)
Jun 19 2019
just a minor comment on one of these...
LGTM, again, really nice. Tiny tweak below.
Jun 18 2019
FWIW, this LGTM. We may want to tweak the behavior around flattening, but that can happen as a follow-up, and this seems to get us to a better state.
OMG, I'm so sorry, I had no idea that the tests would explode like that... Yeah, I don't think that's useful....
Jun 12 2019
LGTM. Bit annoying that we need to do this at O0, but fine...