diff options
author | Craig Topper <craig.topper@intel.com> | 2019-08-20 19:43:48 +0000 |
---|---|---|
committer | Craig Topper <craig.topper@intel.com> | 2019-08-20 19:43:48 +0000 |
commit | 250951abf551bd6d91fcf568739f84f046fe280a (patch) | |
tree | 558ba688febad8fa809d0e5e2e8307ecc7b8f826 /lldb/packages/Python/lldbsuite/test/expression_command/context-object-objc | |
parent | 57ae6b8e377c8af41c9a017fe9b7c7f4b2fc04f7 (diff) | |
download | bcm5719-llvm-250951abf551bd6d91fcf568739f84f046fe280a.tar.gz bcm5719-llvm-250951abf551bd6d91fcf568739f84f046fe280a.zip |
[X86] Add isel patterns for (i64 (zext (i8 (bitcast (v16i1 X))))) to use a KMOVW and a SUBREG_TO_REG. Similar for i8 and anyextend.
We already had patterns for extending to i32 to take advantage of
the impliciting zeroing of the upper bits of a 32-bit GPR that is
done by KMOVW/KMOVB. But the extend might be all the way to i64,
in which case the existing patterns would fail and we'd get a
KMOVW/B followed by a MOVZX. By adding patterns for i64 we can
use the fact that KMOVW/B zero the upper bits of the 32-bit GPR
and the normal property that 32-bit GPR writes implicitly zero the
upper 32-bits of the full 64-bit GPR.
The anyextend patterns are slightly different since we don't care
about the upper zeros. For the i8->i64 I think this avoids selecting
the anyextend as a MOVZX to prevent a partial register issue that
doesn't exist. For i16->i64 I think we would have just emitted an
insert_subreg on top of the extract_subreg that the vXi16->i16
bitcast pattern emits. The register coalescer or peephole pass
should combine those, but this saves that work and makes i8/16
consistent.
llvm-svn: 369431
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/expression_command/context-object-objc')
0 files changed, 0 insertions, 0 deletions