Need either follow the original order of the operands for bool logical
ops, or emit freeze instruction to avoid poison propagation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
11096 | This could use a comment to describe the patterns/logic. IIUC, we want to create a bool logic op like: select i1 LHS, i1 RHS, i1 false ; logical and If we have original code like this: RedOp1 = select i1 ?, i1 LHS, i1 false RedOp2 = select i1 RHS, i1 ?, i1 false Then, we swap LHS/RHS to create a new op that matches the poison semantics of the original code. If we have original code like this and both values could be poison: RedOp1 = select i1 ?, i1 LHS, i1 false RedOp2 = select i1 ?, i1 RHS, i1 false Then, we must freeze LHS in the new op. Can we manufacture a test for this 2nd path? I don't think there's any coverage for that path in the current test diffs. |
Reworked addition of the reduction. For logical ops, reduction result is added as a first operand,
it is safe to use it as an LHS in scalar logical ands/ors.
For others, it is added as a last operand.
llvm/test/Transforms/SLPVectorizer/X86/reduction-logical.ll | ||
---|---|---|
312–313 | The updated patch does not fix the bug? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
10312–10315 | I think we should just fix this to include isa<SelectInst>, so it matches the code comment. Then, we don't need the confusing extra variable in this patch. All of the existing uses are checking for SelectInst, so that can be a preliminary cleanup patch. |
I think we should just fix this to include isa<SelectInst>, so it matches the code comment. Then, we don't need the confusing extra variable in this patch. All of the existing uses are checking for SelectInst, so that can be a preliminary cleanup patch.