diff options
| author | Craig Topper <craig.topper@intel.com> | 2019-06-24 17:28:41 +0000 |
|---|---|---|
| committer | Craig Topper <craig.topper@intel.com> | 2019-06-24 17:28:41 +0000 |
| commit | 7fccb2ac5e32c074b91411f80da5a038c12489a5 (patch) | |
| tree | d86faaa4c2bae4a6f020e683c272aa67e9888d63 /lldb/packages/Python/lldbsuite/test/python_api/signals/main.cpp | |
| parent | 033774e144bd18a55eaee783d08d5f2a89b44af8 (diff) | |
| download | bcm5719-llvm-7fccb2ac5e32c074b91411f80da5a038c12489a5.tar.gz bcm5719-llvm-7fccb2ac5e32c074b91411f80da5a038c12489a5.zip | |
[X86] Don't a vzext_movl in LowerBuildVectorv16i8/LowerBuildVectorv8i16 if there are no zeroes in the vector we're building.
In LowerBuildVectorv16i8 we took care to use an any_extend if the first pair is in the lower 16-bits of the vector and no elements are 0. So bits [31:16] will be undefined. But we still emitted a vzext_movl to ensure that bits [127:32] are 0. If we don't need any zeroes we should be consistent and make all of 127:16 undefined.
In LowerBuildVectorv8i16 we can just delete the vzext_movl code because we only use the scalar_to_vector when there are no zeroes. So the vzext_movl is always unnecessary.
Found while investigating whether (vzext_movl (scalar_to_vector (loadi32)) patterns are necessary. At least one of the cases where they were necessary was where the loadi32 matched 32-bit aligned 16-bit extload. Seemed weird that we required vzext_movl for that case.
Differential Revision: https://reviews.llvm.org/D63700
llvm-svn: 364207
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/signals/main.cpp')
0 files changed, 0 insertions, 0 deletions
