This commit enhances the ComplexDeinterleaving pass to handle unordered
reductions in simple one-block vectorized loops, supporting both
SVE and Neon architectures.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks good, just a couple of small points from me today.
llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp | ||
---|---|---|
386–391 | Might be worth adding a comment here saying what it returns, it's not immediately clear to me | |
1734–1787 | This function is getting big. Solely in terms of readability, I'd suggest moving the code for each condition to separate functions, leaving the ifs here (at least the ReductionOperation branch, ReductionPHI is small enough on its own) |
llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp | ||
---|---|---|
1734–1787 | What do you think about this version? |
Made changes to the checkNodes method in how it verifies reduction nodes.
Additionally, the final reduction operation is now generated at the beginning of the basic block to prevent broken IR.
LGTM, nice work
llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp | ||
---|---|---|
1808 | Nit: May be worth adding a default case for this switch. Something simple like the following default: llvm_unreachable("Unhandled case in ComplexDeinterleavingGraph::replaceNode"); break; |
llvm/lib/CodeGen/ComplexDeinterleavingPass.cpp | ||
---|---|---|
1435 | Iterating over std::map<Instruction *, ... here causes codegen non-determinism as the order depends on the memory addresses, so the order may different across different runs. I pushed a fix to use MapVector instead: https://github.com/llvm/llvm-project/commit/4c9223c77062bc93f63039c9ebdd885d0f50de59 Spotting such issues can be very difficult and we need to be careful when the iteration order can be non-deterministic |
Might be worth adding a comment here saying what it returns, it's not immediately clear to me