summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/WebAssembly/Disassembler
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2019-06-04 16:40:04 +0000
committerSanjay Patel <spatel@rotateright.com>2019-06-04 16:40:04 +0000
commit606eb2367f9f0bef2d1e0182bbb2bf4effb1711e (patch)
tree07ad29ff737cfeb198014fa795f057a9150954e6 /llvm/lib/Target/WebAssembly/Disassembler
parentf15e3d856fddd3ecf80fdbb798be64d0c4bc6de4 (diff)
downloadbcm5719-llvm-606eb2367f9f0bef2d1e0182bbb2bf4effb1711e.tar.gz
bcm5719-llvm-606eb2367f9f0bef2d1e0182bbb2bf4effb1711e.zip
[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 a 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: 362524
Diffstat (limited to 'llvm/lib/Target/WebAssembly/Disassembler')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud