summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/value/main.c
diff options
context:
space:
mode:
authorAhmed Bougacha <ahmed.bougacha@gmail.com>2016-03-03 16:53:50 +0000
committerAhmed Bougacha <ahmed.bougacha@gmail.com>2016-03-03 16:53:50 +0000
commit671795a9855fdb74bd18d963137a006ced9d92aa (patch)
treeb0e0efeda37656a24d2e931bb6b1c22306196dbc /lldb/packages/Python/lldbsuite/test/python_api/value/main.c
parent1130935c4ab127fa4204b2d3a2b4025c52ad76af (diff)
downloadbcm5719-llvm-671795a9855fdb74bd18d963137a006ced9d92aa.tar.gz
bcm5719-llvm-671795a9855fdb74bd18d963137a006ced9d92aa.zip
[X86] Don't assume that shuffle non-mask operands starts at #0.
That's not the case for VPERMV/VPERMV3, which cover all possible combinations (the C intrinsics use a different order; the AVX vs AVX512 intrinsics are different still). Since: r246981 AVX-512: Lowering for 512-bit vector shuffles. VPERMV is recognized in getTargetShuffleMask. This breaks assumptions in most callers, as they expect the non-mask operands to start at index 0. VPERMV has the mask as operand #0; VPERMV3 has it in the middle. Instead of the faulty assumption, have getTargetShuffleMask return its operands as well. One alternative we considered was to change the operand order of VPERMV, but we agreed to stick to the instruction order, as there are more AVX512 weirdness to cover (vpermt2/vpermi2 in particular). Differential Revision: http://reviews.llvm.org/D17041 llvm-svn: 262627
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/value/main.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud