This change allow continue scanning to find a loaded value through single predecessors, instead of being limited within the current block, while respecting the backward scan limit.
Diff Detail
Event Timeline
I'm going to ask the same question i did about the jumpthreading case:
This seems to be a thing other passes get, and do it cheaper.
I would rather see us *remove this code entirely* than extend it. We don't need to do everything everywhere.
The testcases given are optimizations we will get elsewhere.
If there are good reasons to do this in instcombine, great, let's test those reasons :)
I also observed this change was applied pretty widely in my spec2000/2006 and had impacts on the final output code, which means the opportunities are exposed in InstCombin and they are not handled in other places in the whole pipeline; let me try to reduce such case from my spec tests. I added the testcase to describe what this patch do in instcombine itself, not to show the case which can only be handled in instcombine.
We definitely should investigate that.
Because that is very worrying, and we should definitely fix those deficiencies. But without seeing them,i'm not sure i'd fix them in instcombine, and the general preference would be "make pass that should be catching it, catch it
let me try to reduce such case from my spec tests. I added the testcase to describe what this patch do in instcombine itself, not to show the case which can only be handled in instcombine.
Sure, but i'd like us to try to test stuff that is specific to the pass.
Otherwise, we'd even be better off unifying these tests in a single place and testing every pass that can do it.
(IE we have no reason to copy the same test 20 times in the codebase)
;)