summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2018-04-22 17:07:44 +0000
committerSanjay Patel <spatel@rotateright.com>2018-04-22 17:07:44 +0000
commit30be665e82989243f5a9b4c71ec1805c59b376ec (patch)
treee1865da5b1e432b58a85d56dd8d296c3dd5f0e1d /clang/lib/Frontend/CompilerInvocation.cpp
parentc7f9b183c2551dc478ff2b55b287e900dc8719f8 (diff)
downloadbcm5719-llvm-30be665e82989243f5a9b4c71ec1805c59b376ec.tar.gz
bcm5719-llvm-30be665e82989243f5a9b4c71ec1805c59b376ec.zip
[PatternMatch] allow undef elements when matching a vector zero
This is the last step in getting constant pattern matchers to allow undef elements in constant vectors. I'm adding a dedicated m_ZeroInt() function and building m_Zero() from that. In most cases, calling code can be updated to use m_ZeroInt() directly when there's no need to match pointers, but I'm leaving that efficiency optimization as a follow-up step because it's not always clear when that's ok. There are just enough icmp folds in InstSimplify that can be used for integer or pointer types, that we probably still want a generic m_Zero() for those cases. Otherwise, we could eliminate it (and possibly add a m_NullPtr() as an alias for isa<ConstantPointerNull>()). We're conservatively returning a full zero vector (zeroinitializer) in InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify), but I'm not sure if that's actually necessary in all cases. We may be able to propagate an undef lane instead. One test where this happens is marked with 'TODO'. llvm-svn: 330550
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud