diff options
author | Sanjay Patel <spatel@rotateright.com> | 2019-04-11 14:21:57 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2019-04-11 14:21:57 +0000 |
commit | c0f4a35e68af0af8301ec0c0070f8a0d665b157f (patch) | |
tree | 59ea60da31dade361f36ed65f7b7000f31d85ab8 /lldb/packages/Python/lldbsuite/test/python_api/process | |
parent | 8ddfd46c61ab1acf27b3100db5e5720590fb0743 (diff) | |
download | bcm5719-llvm-c0f4a35e68af0af8301ec0c0070f8a0d665b157f.tar.gz bcm5719-llvm-c0f4a35e68af0af8301ec0c0070f8a0d665b157f.zip |
[DAGCombiner][x86] scalarize inserted vector FP ops
// bo (build_vec ...undef, x, undef...), (build_vec ...undef, y, undef...) -->
// build_vec ...undef, (bo x, y), undef...
The lifetime of the nodes in these examples is different for variables versus constants,
but they are all build vectors briefly, so I'm proposing to catch them in this form to
handle all of the leading examples in the motivating test file.
Before we have build vectors, we might have insert_vector_element. After that, we might
have scalar_to_vector and constant pool loads.
It's going to take more work to ensure that FP vector operands are getting simplified
with undef elements, so this transform can apply more widely. In a non-loose FP environment,
we are likely simplifying FP elements to NaN values rather than undefs.
We also need to allow more opcodes down this path. Eg, we don't handle FP min/max flavors
yet.
Differential Revision: https://reviews.llvm.org/D60514
llvm-svn: 358172
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/process')
0 files changed, 0 insertions, 0 deletions