diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2020-04-05 09:46:22 -0400 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2020-04-05 09:48:02 -0400 |
| commit | 538a8f02271b6de817a6b65e3b70f9f1fd6e428d (patch) | |
| tree | 46825e6c2dcd9b43db3668648caedde07e918f75 /lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py | |
| parent | cc6738949de80544aa10847111b86585941ad01f (diff) | |
[InstCombine] convert bitcast-shuffle to vector trunc
As discussed in D76983, that patch can turn a chain of insert/extract
with scalar trunc ops into bitcast+extract and existing instcombine
vector transforms end up creating a shuffle out of that (see the
PhaseOrdering test for an example). Currently, that process requires
at least this sequence: -instcombine -early-cse -instcombine.
Before D76983, the sequence of insert/extract would reach the SLP
vectorizer and become a vector trunc there.
Based on a small sampling of public targets/types, converting the
shuffle to a trunc is better for codegen in most cases (and a
regression of that form is the reason this was noticed). The trunc is
clearly better for IR-level analysis as well.
This means that we can induce "spontaneous vectorization" without
invoking any explicit vectorizer passes (at least a vector cast op
may be created out of scalar casts), but that seems to be the right
choice given that we started with a chain of insert/extract, and the
backend would expand back to that chain if a target does not support
the op.
Differential Revision: https://reviews.llvm.org/D77299
Diffstat (limited to 'lldb/test/API/functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py')
0 files changed, 0 insertions, 0 deletions
