diff options
author | Sanjay Patel <spatel@rotateright.com> | 2018-12-17 20:27:43 +0000 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2018-12-17 20:27:43 +0000 |
commit | 1a6e9ec434319fa0ce20678e14391cb1af0c949b (patch) | |
tree | 8aece28751ae8304e7315ba2578d5145ec6bc01b /lldb/packages/Python/lldbsuite/test/python_api/section/TestSectionAPI.py | |
parent | 4ef5d121dcb9ca0cd63afc5cd56fe52372088d69 (diff) | |
download | bcm5719-llvm-1a6e9ec434319fa0ce20678e14391cb1af0c949b.tar.gz bcm5719-llvm-1a6e9ec434319fa0ce20678e14391cb1af0c949b.zip |
[InstCombine] don't widen an arbitrary sequence of vector ops (PR40032)
The problem is shown specifically for a case with vector multiply here:
https://bugs.llvm.org/show_bug.cgi?id=40032
...and this might mask the original backend bug for ARM shown in:
https://bugs.llvm.org/show_bug.cgi?id=39967
As the test diffs here show, we were (and probably still aren't) doing
these kinds of transforms in a principled way. We are producing more or
equal wide instructions than we started with in some cases, so we still
need to restrict/correct other transforms from overstepping.
If there are perf regressions from this change, we can either carve out
exceptions to the general IR rules, or improve the backend to do these
transforms when we know the transform is profitable. That's probably
similar to a change like D55448.
Differential Revision: https://reviews.llvm.org/D55744
llvm-svn: 349389
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/section/TestSectionAPI.py')
0 files changed, 0 insertions, 0 deletions