diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2019-06-04 16:40:04 +0000 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2019-06-04 16:40:04 +0000 |
| commit | 606eb2367f9f0bef2d1e0182bbb2bf4effb1711e (patch) | |
| tree | 07ad29ff737cfeb198014fa795f057a9150954e6 /llvm/lib/Target/TargetIntrinsicInfo.cpp | |
| parent | f15e3d856fddd3ecf80fdbb798be64d0c4bc6de4 (diff) | |
| download | bcm5719-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/TargetIntrinsicInfo.cpp')
0 files changed, 0 insertions, 0 deletions

