aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/VirtRegMap.cpp
diff options
context:
space:
mode:
authorTim Northover <tnorthover@apple.com>2014-02-06 09:54:51 +0000
committerTim Northover <tnorthover@apple.com>2014-02-06 09:54:51 +0000
commit546b57b011c5f1aa6c5a24a7716d06e01512f934 (patch)
tree7d92f118e74d5f4707865d75695b0c2b9d9ef10e /llvm/lib/CodeGen/VirtRegMap.cpp
parent5eb1004889601ca4d091a855617c8bb5eb0c3170 (diff)
downloadllvm-546b57b011c5f1aa6c5a24a7716d06e01512f934.zip
llvm-546b57b011c5f1aa6c5a24a7716d06e01512f934.tar.gz
llvm-546b57b011c5f1aa6c5a24a7716d06e01512f934.tar.bz2
X86: deduplicate V[SZ]EXT_MOVL and V[SZ]EXT nodes
I believe VZEXT_MOVL means "zero all vector elements except the first" (and should have identical input & output types) whereas VZEXT means "zero extend each element of a vector (discarding higher elements if necessary)". For example: (v4i32 (vzext (v16i8 ...))) should zero extend the low 4 bytes of the incoming vector to 32-bits, discarding higher bytes. However, somewhere in the past, these two concepts had become confused, even leading to a nonsensical VSEXT_MOVL. This re-merges the nodes where appropriate (all VSEXT_MOVL -> VSEXT, VZEXT_MOVL -> VZEXT when it's an actual extension). rdar://problem/15981990 llvm-svn: 200918
Diffstat (limited to 'llvm/lib/CodeGen/VirtRegMap.cpp')
0 files changed, 0 insertions, 0 deletions