summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2018-10-26 14:58:13 +0000
committerSanjay Patel <spatel@rotateright.com>2018-10-26 14:58:13 +0000
commit6b40768f5ad281628185d100c131e8a4c58e6368 (patch)
tree05f28a36894d380c33a53d2de9dcdd617fc3ef22 /lldb/packages/Python/lldbsuite/test
parent7575c6d01b16d68662ddbfbd7007f781881c22f8 (diff)
downloadbcm5719-llvm-6b40768f5ad281628185d100c131e8a4c58e6368.tar.gz
bcm5719-llvm-6b40768f5ad281628185d100c131e8a4c58e6368.zip
[x86] commute blendvb with constant condition op to allow load folding
This is a narrow fix for 1 of the problems mentioned in PR27780: https://bugs.llvm.org/show_bug.cgi?id=27780 I looked at more general solutions, but it's a mess. We canonicalize shuffle masks based on the number of elements accessed from each operand, and that's not optional. If you remove that, we'll crash because we fail to match isel patterns. So I'm waiting until we're sure that we have blendvb with constant condition and then commuting based on the load potential. Other cases like blend-with-immediate are already handled elsewhere, so this is probably not a common problem anyway. I didn't use "MayFoldLoad" because that checks for one-use and in these cases, we've screwed that up by creating a temporary PSHUFB using these operands that we're counting on to be killed later. Undoing that didn't look like a simple task because it's intertwined with determining if we actually use both operands of the shuffle or not.a Differential Revision: https://reviews.llvm.org/D53737 llvm-svn: 345390
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud