[ValueTracking] computeKnownBitsFromOperator - improve Instruction::BitCast handling to match SelectionDAG

[RKSimon]

The middle end computeKnownBitsFromOperator can merge bitcasts from narrow vector elements to wider types, but fails to perform this in the reverse case:

https://github.com/llvm/llvm-project/blob/85d417564b5f959f7434f2657cc9e1ab3575311f/llvm/lib/Analysis/ValueTracking.cpp#L1328:L1361

The SelectionDAG implementation handles both so hopefully its just a case of reusing the additional code over and adding any missing test coverage:

https://github.com/llvm/llvm-project/blob/46befd720995647485c516ba94a49eee5548283a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp#L3662:L3706

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Simon Pilgrim (RKSimon)

The middle end computeKnownBitsFromOperator can merge bitcasts from narrow vector elements to wider types, but fails to perform this in the reverse case:

https://github.com/llvm/llvm-project/blob/85d417564b5f959f7434f2657cc9e1ab3575311f/llvm/lib/Analysis/ValueTracking.cpp#L1328:L1361

The SelectionDAG implementation handles both so hopefully its just a case of reusing the additional code over and adding any missing test coverage:

https://github.com/llvm/llvm-project/blob/46befd720995647485c516ba94a49eee5548283a/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp#L3662:L3706

[RKSimon]

@abhishek-kaushik22 If you're after a middle-end issue to investigate this could be pretty interesting as its affecting x86 SSE intrinsic simplification (which always generate IR with too many casts to/from __m128i <2 x i64> types

[abhishek-kaushik22]

Thanks, I'll take a look :)

[RKSimon]

There's a similar one at #87624 - but I'm not sure if @changkhothuychung has officially given up on it.

[RKSimon]

#include <x86intrin.h>

__m128i shift64(__m128i v, __m128i s)
{
    s = _mm_and_si128(s, _mm_set1_epi64x(63));
    __m128i x_ = _mm_sll_epi64( v, s );
    __m128i _y = _mm_sll_epi64( v, _mm_srli_si128( s, 8 ) );
    __m128i xy = _mm_castpd_si128( _mm_shuffle_pd( _mm_castsi128_pd( x_ ), _mm_castsi128_pd( _y ), _MM_SHUFFLE2(1,0) ) );
    return xy;
}

An example of the failure to peek through bitcasts early enough to simplify @llvm.x86.sse2.psll.q calls, resulting in:

define <2 x i64> @shift64(<2 x i64> %v, <2 x i64> %s) {
entry:
  %and.i = and <2 x i64> %s, splat (i64 63)
  %0 = shufflevector <2 x i64> %and.i, <2 x i64> poison, <2 x i32> zeroinitializer
  %1 = shl <2 x i64> %v, %0
  %2 = shufflevector <2 x i64> %and.i, <2 x i64> poison, <2 x i32> <i32 1, i32 1>
  %3 = shl <2 x i64> %v, %2
  %shufp.uncasted = shufflevector <2 x i64> %1, <2 x i64> %3, <2 x i32> <i32 0, i32 3>
  ret <2 x i64> %shufp.uncasted
}

instead of:

define <2 x i64> @shift64(<2 x i64> %v, <2 x i64> %s) {
entry:
  %and.i = and <2 x i64> %s, splat (i64 63)
  %shl = shl <2 x i64> %v, %and.i
  ret <2 x i64> %shl
}