[DAG][ARM] computeKnownBitsForTargetNode - add handling for ARMISD VORRIMM\VBICIMM nodes

[RKSimon]

If we fold to a VORRIMM\VBICIMM node then valuetracking can no longer analyse the known bits.

Noticed while working on longer term work for #83422 - I haven't created a test case against trunk, but its possible that existing test coverage might already benefit.

[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 is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, 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)

If we fold to a VORRIMM\VBICIMM node then valuetracking can no longer analyse the known bits.

Noticed while working on longer term work for #83422 - I haven't created a test case against trunk, but its possible that existing test coverage might benefit.

[llvmbot]

@llvm/issue-subscribers-backend-arm

Author: Simon Pilgrim (RKSimon)

If we fold to a VORRIMM\VBICIMM node then valuetracking can no longer analyse the known bits.

Noticed while working on longer term work for #83422 - I haven't created a test case against trunk, but its possible that existing test coverage might benefit.

[trnguyen34]

Hi @RKSimon, I'd like to contribute to this. Can I work on it please?

[woruyu]

Hi @trnguyen34 , I hope you don’t mind me asking—are you still planning to work on this?
If you're no longer available, I’d be happy to help out. Totally understand if you’re still on it!

[trnguyen34]

Hi @woruyu, I'm still working on it but I'd be happy to work on it with you.

[woruyu]

Hi @trnguyen34, thanks for the update!

I’ve already posted a draft PR for the ARMISD::VORRIMM support in computeKnownBitsForTargetNode, but I haven’t found a minimal test case that clearly exercises the new logic.

One tricky part is that the immediate operand in VORRIMM is actually an encoded value, not the real splat constant. So to get correct known bits, we need to call ARM_AM::decodeVMOVModImm with the proper element size. Just using getConstantOperandAPInt gives the wrong result in many cases.

If you’d like to verify or experiment with this, the following function is a good way to trigger the pattern:

; RUN: llc < %s -mtriple armv7-linux-gnueabihf -mattr=+neon | FileCheck %s
define void @test_v2i8(ptr %p) {
  %a = load <2 x i8>, ptr %p
  %tmp = call <2 x i8> @llvm.cttz.v2i8(<2 x i8> %a, i1 false)
  store <2 x i8> %tmp, ptr %p
  ret void
}

This will eventually lower into a sequence containing VORRIMM, so it’s useful for testing both codegen and known bits behavior.

Hope my suggestions and the draft PR help make the problem clearer and help you understand it clearer!

[woruyu]

Hi @trnguyen34, form draft PR's review, maybe we need add a small test case in AArch64SelectionDAGTest.
Would you be interested in trying that, No pressure at all and I’d be happy to help however I can.