diff options
| author | Philip Reames <listmail@philipreames.com> | 2022-01-28 10:34:16 -0800 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2022-01-28 11:08:59 -0800 |
| commit | db49a78900f5e4b59714565876b5dbb5e2dfe840 (patch) | |
| tree | f429d514b69bce5d2cd185aa2ae4a4b34fd5507f /llvm/lib/CodeGen/MachineModuleInfo.cpp | |
| parent | 277123376ce08c98b07c154bf83e4092a5d4d3c6 (diff) | |
| download | llvm-db49a78900f5e4b59714565876b5dbb5e2dfe840.zip llvm-db49a78900f5e4b59714565876b5dbb5e2dfe840.tar.gz llvm-db49a78900f5e4b59714565876b5dbb5e2dfe840.tar.bz2 | |
[SLP] Add a clarifying assert in block scheduling [NFC]
The fact we could have a block with a valid scheduling window, but nothing to schedule was surprising to me. After digging through the code, this can only happen if we don't find anything to directly vectorize. However, the reduction handling code relies on this mode, so we can't simply consider such trees unvectorizeable. The assert conveys both that this situation can happen, but also that it can *only* happen for an immediate gather.
Context: We built the bundle before deciding that vectorization of a bundle is possible. A side effect of bundle construction is manipulating the scheduling window, so a bundle which isn't vectorizable can cause the creation or expansion of a scheduling window.
Diffstat (limited to 'llvm/lib/CodeGen/MachineModuleInfo.cpp')
0 files changed, 0 insertions, 0 deletions