This transform is copied from foldICmpEqIntrinsicWithConstant,
it is safe to re-use undef elts in a vector.
This patch complete it in foldICmpInstWithConstantNotInt.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This approach will not scale well. There are many transforms where we can allow undefs, but we did not bother to do it because there was no immediate motivation.
Also, if we are duplicating code/logic, then we are increasing the risk of bugs that are very hard to test/notice.
I would prefer that we back through the callers to the line where C was captured and allow matching vectors with undefs (m_APIntAllowUndef). Then add a parameters/logic to decide if a vector constant with undef is acceptable.
If that is too hard, then add an alternate code path from the caller for transforms where undef is allowed. Then move the transform under that caller rather than copying code.
Yer, I agree with you, but there are too many functions involved. I will try to do it. As a first step I will simplify function ‘foldICmpInstWithConstant’ D125457.
llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp | ||
---|---|---|
3042–3043 | This comment is not needed. The comment above the new function is enough. | |
3287–3288 | Delete this comment. We did not copy the transform (because that would be bad design). We moved it. The safety of allowing undef is already mentioned in the function-level comment and the function name, so there is no need to repeat it here. | |
llvm/test/Transforms/InstCombine/icmp-fsh.ll | ||
64 | We should add one more test that has "eq zero with undef", so the transform has better coverage. If there is not a test for a non-zero and non-negative-one, then please add that too. Then we know the transform does not happen with something like "<i5 undef, i5 1>". |
llvm/test/Transforms/InstCombine/icmp-fsh.ll | ||
---|---|---|
64 | I have committed tests, and the negative tests follow here. |
LGTM - if you are planning to enhance more folds to allow undef in vector constants, please test correctness with Alive2. It is true that there are more folds like this, but it is not correct to propagate undef elements in general.
Please wait for @RKSimon for final approval.
This comment is not needed. The comment above the new function is enough.