summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2017-02-03 23:13:11 +0000
committerSanjay Patel <spatel@rotateright.com>2017-02-03 23:13:11 +0000
commit0fe32ac256c2582315c4f58039f351b362ae7672 (patch)
tree8c249ab6e1439d4fa94fbbc5bb945a58a84e037a /lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h
parent9e838bd1427dffafdc54e1b2c346db91f543e265 (diff)
downloadbcm5719-llvm-0fe32ac256c2582315c4f58039f351b362ae7672.tar.gz
bcm5719-llvm-0fe32ac256c2582315c4f58039f351b362ae7672.zip
[InstCombine] treat i1 as a special type in shouldChangeType()
This patch is based on the llvm-dev discussion here: http://lists.llvm.org/pipermail/llvm-dev/2017-January/109631.html Folding to i1 should always be desirable because that's better for value tracking and we have special folds for i1 types. I checked for other users of shouldChangeType() where this might have an effect, but we already handle the i1 case differently than other types in all of those cases. Side note: the default datalayout includes i1, so it seems we only find this gap in shouldChangeType + phi folding for the case when there is (1) an explicit datalayout without i1, (2) casting to i1 from a legal type, and (3) a phi with exactly 2 incoming casted operands (as Björn mentioned). Differential Revision: https://reviews.llvm.org/D29336 llvm-svn: 294066
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud