This drastically reduces the time this pass takes on larger modules (15 minutes to 30 seconds on a 500MB LTO module I'm working with)
Thanks, that sounds like a really good improvement!
I just wanted to quickly check your testing strategy. Problem is function specialisation isn't enabled by default, so isn't covered by the upstream buildbots and tests. I shot myself in the foot recently by introducing a performance regression that I noticed later and then took me more time to fix (I am tracking performance now with function specialisation enabled).
I usually hack the compiler in Transforms/IPO/PassManagerBuilder.cpp:175 as I find that easier to pass flags in different build systems and change cl::init(false) into true, and then run some code: a stage2 build would be good, and the llvm test suite too, these would be the minimum and function specialisation should trigger in both. And sorry if you're doing this already, but just wanted to check. If you can it would be good if you run SPEC too and see that the MCF score is unaffected (with LTO that is, it should trigger on MCF so if it doesn't anymore we have a problem :) ).
But I think I can quickly run SPEC today, so will do that and report back here.
This is supplemented by the replaceUsesOfWith in the patch. However, when looking over this, I realized that the way I submitted this is just plain wrong.
Thanks for updating this. Now it looks more reasonable. But I am still confused. After line 304, V shouldn't have any uses, right? So how could we replace uses for V on line 308?
My testing "strategy" at the moment is essentially just throwing this insane LTO module at it and seeing whether it breaks or not. Problem is I have a lot of weird patches on the pass at the moment so it's somewhat difficult to isolate individual things to upstream. Will try running tests later.
Oh, I see what you mean now. You're right, this should be in the diff too.
That's a good start! :-) But yeah, please try to test more (the llvm regr tests are a no brainer), but like I said at least the llvm test suite and a stage2 build would be good.
I've run SPEC and that seems unaffected so is good.
I haven't looked much into this change itself to be honest (thanks @ChuanqiXu ), but the different iterations of this patch makes me wonder if some of this could or should have been caught by regression tests. Are we missing some coverage there?
That's a good point, I can try to create a test case that would break the previous version of this patch.
But now that I think about it, is this necessary at all? We're not changing the value to something completely different, and the solver already knows it's constant which means this information has already been backpropagated to the user list.
This would also explain why the previous patches didn't break any tests; this code might essentially be a no-op.
Also further supported by the fact that SCCP doesn't do this either.
This comment may be confusing. We could understand this comment due to we are visiting this diff page. But other readers may be confused about this since they lost the context.