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
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
120 | 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 | ||
---|---|---|
121–130 | 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; } | |
199–201 | 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 | ||
---|---|---|
120 | 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 | ||
---|---|---|
120 | Given that we get the constant via running a custom instsimplify | |
199–201 | Good comments are always good :) |
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
199–201 | 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 | ||
---|---|---|
199–201 | 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 | ||
---|---|---|
199–201 | 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. |
I'm open to suggestions about this function and it's name.