summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/CodeGen/GlobalISel/PatternMatchTest.cpp
diff options
context:
space:
mode:
authorChad Rosier <mcrosier@codeaurora.org>2018-03-09 16:43:46 +0000
committerChad Rosier <mcrosier@codeaurora.org>2018-03-09 16:43:46 +0000
commit95d9ccb2a0542d79ecf40f14784be20f96b494b1 (patch)
treec51f472f4da6ea423d01362cea32aa957a550bcf /llvm/unittests/CodeGen/GlobalISel/PatternMatchTest.cpp
parentebda41f812925cf1332b317ed725da2dd181182a (diff)
downloadbcm5719-llvm-95d9ccb2a0542d79ecf40f14784be20f96b494b1.tar.gz
bcm5719-llvm-95d9ccb2a0542d79ecf40f14784be20f96b494b1.zip
[JumpThreading] Don't restrict cast-traversal to i1
In r263618, JumpThreading learned to look trough simple cast instructions, but only if the source of those cast instructions was a phi/cmp i1 (in an effort to limit compile time effects). I think this condition is too restrictive. For switches with limited value range, InstCombine will readily introduce an extra trunc instruction to a smaller integer type (e.g. from i8 to i2), leaving us in the somewhat perverse situation that jump-threading would work before running instcombine, but not after. Since instcombine produces this pattern, I think we need to consider it canonical and support it in JumpThreading. In general, for limiting recursion, I think the existing restriction to phi and cmp nodes should be sufficient to avoid looking through unprofitable chains of instructions. Patch by Keno Fischer! Differential Revision: https://reviews.llvm.org/D42262 llvm-svn: 327150
Diffstat (limited to 'llvm/unittests/CodeGen/GlobalISel/PatternMatchTest.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud