aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/XCOFFObjectFile.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2019-05-28 13:54:17 +0000
committerSanjay Patel <spatel@rotateright.com>2019-05-28 13:54:17 +0000
commitd5a8637072f4c556b88156bd2f6237a2ead47d31 (patch)
treed311a078955e4ace833057013b1fbb8bc95d4c3a /llvm/lib/Object/XCOFFObjectFile.cpp
parent9cd9624fb68db36835229ba5b08f9797b2f9d16b (diff)
downloadllvm-d5a8637072f4c556b88156bd2f6237a2ead47d31.zip
llvm-d5a8637072f4c556b88156bd2f6237a2ead47d31.tar.gz
llvm-d5a8637072f4c556b88156bd2f6237a2ead47d31.tar.bz2
[x86] split 256-bit store of concatenated vectors
This shows up as a side issue to the main problem for the AVX target example from PR37428: https://bugs.llvm.org/show_bug.cgi?id=37428 - https://godbolt.org/z/7tpRa3 But as we can see in the pile of existing test diffs, it's actually a widespread problem that affects any AVX or later target. Apart from a couple of oddballs, I think these are all improvements for the reasons stated in the code comment: we do not want to enable YMM unnecessarily (avoid vzeroupper and frequency throttling) and some cores split 256-bit stores anyway. We could say that MergeConsecutiveStores() is going overboard on some of these examples, but that won't solve the problem completely. But that is the reason I'm proposing this as a lowering rather than a combine: we will infinite loop fighting the merge code if we try this earlier. Differential Revision: https://reviews.llvm.org/D62498 llvm-svn: 361822
Diffstat (limited to 'llvm/lib/Object/XCOFFObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions