[x86] Fix a bug in my new zext-vector-inreg DAG trickery where we were
authorChandler Carruth <chandlerc@gmail.com>
Wed, 9 Jul 2014 12:36:54 +0000 (12:36 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Wed, 9 Jul 2014 12:36:54 +0000 (12:36 +0000)
commit5865a73a8249be95bcd786102a62f8956d5ed1b3
tree3657984682e5677105796e960bf6960d8c5a3078
parent0acd5447b45f76b5a3a84990846a4cc421f0b4b6
[x86] Fix a bug in my new zext-vector-inreg DAG trickery where we were
not widening the input type to the node sufficiently to let the ext take
place in a register.

This would in turn result in a mysterious bitcast assertion failure
downstream. First change here is to add back the helpful assert I had in
an earlier version of the code to catch this immediately.

Next change is to add support to the type legalization to detect when we
have widened the operand either too little or too much (for whatever
reason) and find a size-matched legal vector type to convert it to
first. This can also fail so we get a new fallback path, but that seems
OK.

With this, we no longer crash on vec_cast2.ll when using widening. I've
also added the CHECK lines for the zero-extend cases here. We still need
to support sign-extend and trunc (or something) to get plausible code
for the other two thirds of this test which is one of the regression
tests that showed the most scalarization when widening was
force-enabled. Slowly closing in on widening being a viable legalization
strategy without it resorting to scalarization at every turn. =]

llvm-svn: 212614
llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
llvm/test/CodeGen/X86/vec_cast2.ll