When we do ConstantExpr::getZExt(), that "extends" undef to 0,
which means that for patterns a/b we'd assume that we must not produce
any bits for that channel, while in reality we simply didn't care
about that channel - i.e. we don't need to mask it.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
116 ↗ | (On Diff #222475) | I'm open to suggestions about this function and it's name. |
I'd be okay with either spliting this up further if wanted, or moving this particular patch
into post-commit review mode; the only worrying thing to me here is the sanitizeUndefsTo() itself.
I'm a patch minimalist, so if we can split this up, let's do it.
We should not use "sanitize" in the function name because that term already has a special meaning in the clang/LLVM world.
Cool, will post in a sec..
We should not use "sanitize" in the function name because that term already has a special meaning in the clang/LLVM world.
Any suggestions? replaceUndefsWith?
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
117–126 ↗ | (On Diff #223232) | I suppose it's a matter of C++ familiarity, but this logic is not obvious to me. I think it's easier to read as something like: unsigned NumElts = CV->getType()->getVectorNumElements(); for (unsigned i = 0; i != NumElts; ++i) { Constant *EltC= CV->getOperand(i); NewOps[i] = match(EltC, m_Undef()) ? Replacement : EltC; } |
190–192 ↗ | (On Diff #223232) | Probably worth explaining this more directly, and what if we make it consistent by replacing with -1? // An extend of an undef value becomes zero because the // high bits are never completely unknown. Replace the // the shift amount with -1 to ensure that the value remains // undef when creating the subsequent shift op. |
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
116 ↗ | (On Diff #223232) | Is it possible to get here with a scalar undef? If so, this doesn't replace it. If not, do we want to assert that we have a vector constant? |
Addressed review notes.
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
116 ↗ | (On Diff #223232) | Given that we get the constant via running a custom instsimplify |
190–192 ↗ | (On Diff #223232) | Good comments are always good :) |
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
190–192 ↗ | (On Diff #223232) | Why is using different variants based on bidwidth better? Or does -1 not work as a poisonous shift amount? |
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
190–192 ↗ | (On Diff #223232) | In this branch - yes, i think -1 should work. Let me know if that explanation does not make any sense. |
LGTM
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
190–192 ↗ | (On Diff #223232) | Ok, I see what you mean. It seems like we're missing some analysis that would handle this sort of thing for us cleanly, but I don't see where/how to implement it, so I won't hold this up. |