niyue commented on issue #37834: URL: https://github.com/apache/arrow/issues/37834#issuecomment-1733062773
@kou I gave it a try to update Gandiva's code to use the new LLVM PassManager: https://github.com/apache/arrow/compare/main...niyue:arrow:feature/new-passmanager But one of the test case failed: ``` TEST_F(TestLLVMGenerator, TestAdd) { // .... std::string fn_name = "codegen"; ASSERT_OK(generator->engine_->LoadFunctionIRs()); ASSERT_OK(generator->CodeGenExprValue(func_dex, 4, desc_sum, 0, fn_name, SelectionVector::MODE_NONE)); ASSERT_OK(generator->engine_->FinalizeModule()); auto ir = generator->engine_->DumpIR(); EXPECT_THAT(ir, testing::HasSubstr("vector.body")); ``` `EXPECT_THAT(ir, testing::HasSubstr("vector.body"));` This assertion failed with message like this: ``` Value of: ir Expected: has substring "vector.body" Actual: "; ModuleID = 'codegen'\nsource_filename = \"codegen\"\ntarget datalayout = \"e-m:o-i64:64-i128:128-n32:64-S128\"\ntarget triple = \"arm64-apple-macosx13.0.0\"\n\n; Function Attrs: nofree norecurse nosync nounwind\ndefine i32 @codegen(i64* nocapture readonly %inputs_addr, i64* nocapture readonly %inputs_addr_offsets, i64* nocapture readnone %local_bitmaps, i64* nocapture readnone %holder_ptrs, i16* nocapture readnone %selection_vector, i64 %context_ptr, i64 %nrecords) local_unnamed_addr #0 {\nentry:\n %out_mem_addr = getelementptr i64, i64* %inputs_addr, i64 4\n %out_mem = load i64, i64* %out_mem_addr, align 8\n %out_darray = inttoptr i64 %out_mem to i32*\n %0 = load i64, i64* %inputs_addr_offsets, align 8\n %1 = getelementptr i64, i64* %inputs_addr_offsets, i64 2\n %2 = load i64, i64* %1, align 8\n %f0_mem = load i64, i64* %inputs_addr, align 8\n %f0_darray = inttoptr i64 %f0_mem to i32*\n %f1_mem_addr = getelementptr i64, i64* %inputs_addr, i64 2\n %f1_mem = load i64, i64* %f1_mem_addr, align 8\n %f1_darray = inttoptr i64 %f1_mem to i32*\n %smax = call i64 @llvm.smax.i64(i64 %nrecords, i64 1)\n %scevgep6 = getelementptr i32, i32* %f1_darray, i64 %2\n %scevgep9 = getelementptr i32, i32* %f0_darray, i64 %0\n br label %loop\n\nloop: ; preds = %loop, %entry\n %lsr.iv10 = phi i32* [ %scevgep11, %loop ], [ %scevgep9, %entry ]\n %lsr.iv7 = phi i32* [ %scevgep8, %loop ], [ %scevgep6, %entry ]\n %lsr.iv5 = phi i32* [ %scevgep, %loop ], [ %out_darray, %entry ]\n %lsr.iv = phi i64 [ %lsr.iv.next, %loop ], [ %smax, %entry ]\n %f0 = load i32, i32* %lsr.iv10, align 4\n %f1 = load i32, i32* %lsr.iv7, align 4\n %3 = add nsw i32 %f1, %f0\n store i32 %3, i32* %lsr.iv5, align 4\n %lsr.iv.next = add nsw i64 %lsr.iv, -1\n %scevgep = getelementptr i32, i32* %lsr.iv5, i64 1\n %scevgep8 = getelementptr i32, i32* %lsr.iv7, i64 1\n %scevgep11 = getelementptr i32, i32* %lsr.iv10, i64 1\n %exitcond.not = icmp eq i64 %lsr.iv.next, 0\n br i1 %exitcond.not, label %exit, label %loop\n\nexit: ; preds = %loop\n ret i32 0\n}\n\n; Function Attrs: nofree nosync nounwind readnone speculatable willreturn\ndeclare i64 @llvm.smax.i64(i64, i64) #1\n\nattributes #0 = { nofree norecurse nosync nounwind }\nattributes #1 = { nofree nosync nounwind readnone speculatable willreturn }\n\n!llvm.ident = !{!0, !0, !0, !0, !0, !0, !0, !0, !0, !0, !0}\n!llvm.module.flags = !{!1, !2, !3, !4, !5, !6, !7, !8, !9}\n\n!0 = !{!\"Homebrew clang version 14.0.6\"}\n!1 = !{i32 2, !\"SDK Version\", [2 x i32] [i32 13, i32 3]}\n!2 = !{i32 1, !\"wchar_size\", i32 4}\n!3 = !{i32 1, !\"branch-target-enforcement\", i32 0}\n!4 = !{i32 1, !\"sign-return-address\", i32 0}\n!5 = !{i32 1, !\"sign-return-address-all\", i32 0}\n!6 = !{i32 1, !\"sign-return-address-with-bkey\", i32 0}\n!7 = !{i32 7, !\"PIC Level\", i32 2}\n!8 = !{i32 7, !\"uwtable\", i32 1}\n!9 = !{i32 7, !\"frame-poin ter\", i32 1}\n" ``` I've observed that the code I developed produces a different IR compared to the previously generated IR. Notably, the vector.body is absent in the IR, which I suspect is related to loop vectorization. I've attempted to troubleshoot by commenting out certain passes and adjusting the optimization level, but to no avail. I'm not well-versed in this area, so any insights or guidance would be greatly appreciated. Thank you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
