================
@@ -0,0 +1,304 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --version 4
+; RUN: llc < %s -march=bpf | FileCheck %s
+
+; test that we can expand CTTZ & CTLZ
+
+declare i32 @llvm.cttz.i32(i32, i1)
+
+define i32 @cttz_i32_zdef(i32 %a) {
+; CHECK-LABEL: cttz_i32_zdef:
----------------
inclyc wrote:
> (As we don't really test the expansion logic, we just test that some
> expansion is applied)
Hmm, I'm worried about if we do at tests like
```
; CHECK-LABEL: cttz_i32_zdef:
; CHECK: r0 =
; CHECK: exit
```
how can this catch BPF backend changes like `setOperationAction()` to `Custom`
and do some custom lowering, as if custom lowering might be incorrect though?
I think we should test implementation details about "how to expand / custom"
actually. For example if someone really changes the logic of expansion, I think
these tests shall be regenerated and we can see such patches (touched our
backend tests)
https://github.com/llvm/llvm-project/pull/73668
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
