[PATCH] D111661: [FuncSpec] Only visit uses of the instruction instead of every constant use.

Wed Oct 13 08:17:27 PDT 2021

duck-37 added a comment.

In D111661#3061399 <https://reviews.llvm.org/D111661#3061399>, @SjoerdMeijer wrote:

> In D111661#3061016 <https://reviews.llvm.org/D111661#3061016>, @duck-37 wrote:
>
>> In D111661#3060651 <https://reviews.llvm.org/D111661#3060651>, @SjoerdMeijer wrote:
>>
>>> 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.
>>
>> 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.
>
> 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. 
Now that I think about it, is this necessary at all? We're not changing the value to something else, and the solver already knows it's constant which means this information has already been backpropagated to the user list.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111661/new/

https://reviews.llvm.org/D111661