This is an archive of the discontinued LLVM Phabricator instance.

[InstCombin] Continue scanning loaded values through single predecessors
Needs ReviewPublic

Authored by junbuml on Feb 15 2017, 12:14 PM.

Details

Summary

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

junbuml created this revision.Feb 15 2017, 12:14 PM
junbuml updated this revision to Diff 88591.Feb 15 2017, 12:21 PM
junbuml updated this revision to Diff 88593.Feb 15 2017, 12:38 PM

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.

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;

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)
;)

mcrosier resigned from this revision.Jul 26 2017, 6:06 AM