diff options
author | Sanjay Patel <spatel@rotateright.com> | 2018-09-25 19:09:34 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2018-09-25 19:09:34 +0000 |
commit | 10c11b867a045ee6f5ada9b741dbf2929d8d7ae0 (patch) | |
tree | 153d88a3398b84c933d3581a439842224b30d0c1 /lldb/packages/Python/lldbsuite/test/sample_test | |
parent | 7c18d6083ab5e0ba0c9b720be5f4b7fc80b9c958 (diff) | |
download | bcm5719-llvm-10c11b867a045ee6f5ada9b741dbf2929d8d7ae0.tar.gz bcm5719-llvm-10c11b867a045ee6f5ada9b741dbf2929d8d7ae0.zip |
[x86] avoid 256-bit andnp that requires insert/extract with AVX1 (PR37449)
This is the final (I hope!) problem pattern mentioned in PR37749:
https://bugs.llvm.org/show_bug.cgi?id=37749
We are trying to avoid an AVX1 sinkhole caused by having 256-bit bitwise logic ops but no other 256-bit integer ops.
We've already solved the simple logic ops, but 'andn' is an x86 special. I looked at alternative solutions like
extending the generic DAG combine or trying to wait until the ANDNP node is created, but those are bigger patches
that can over-reach. Ie, splitting to 128-bit does not look like a win in most cases with >1 256-bit op.
The pattern matching is cluttered with bitcasts because of our i64 element canonicalization. For the affected test,
we have this vector-type-legalized sequence:
t29: v8i32 = concat_vectors t27, t28
t30: v4i64 = bitcast t29
t18: v8i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-1>, ...
t31: v4i64 = bitcast t18
t32: v4i64 = xor t30, t31
t9: v8i32 = BUILD_VECTOR Constant:i32<255>, Constant:i32<255>, ...
t34: v4i64 = bitcast t9
t35: v4i64 = and t32, t34
t36: v8i32 = bitcast t35
t37: v4i32 = extract_subvector t36, Constant:i64<0>
t38: v4i32 = extract_subvector t36, Constant:i64<4>
Differential Revision: https://reviews.llvm.org/D52318
llvm-svn: 343008
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/sample_test')
0 files changed, 0 insertions, 0 deletions