[Mono] LLVM AOT failed to compile System.Private.CoreLib.dll on amd64

[fanyang-mono]

LLVM AOT failed to compile System.Private.CoreLib.dll on amd64 because of an issue related to X86Base.DivRem intrinsics

Both operands to a binary operator are not of the same type!
  %2 = shl i64 %1, i32 32
; Function Attrs: "?ɯ~???`?}?}?
                               ֚?"
define hidden monocc { i64 } @System_Runtime_Intrinsics_X86_X86Base_DivRem_uint_uint_uint(i32 %arg_lower, i32 %arg_upper, i32 %arg_divisor) #6 {
BB0:
  %vreg_loc_28 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  %vreg_loc_25 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  %vreg_loc_16 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  br label %INIT_BB1

INIT_BB1:                                         ; preds = %BB0
  br label %INITED_BB2

INITED_BB2:                                       ; preds = %INIT_BB1
  br label %BB2

BB2:                                              ; preds = %INITED_BB2
  br label %BB3

BB3:                                              ; preds = %BB2
  %0 = zext i32 %arg_lower to i64
  %1 = zext i32 %arg_upper to i64
  %2 = shl i64 %1, i32 32
  %3 = or i64 %0, %2
  %4 = zext i32 %arg_divisor to i64
  %5 = udiv i64 %3, %4
  %6 = trunc i64 %5 to i32
  %7 = urem i64 %3, %4
  %8 = trunc i64 %7 to i32
  %9 = getelementptr i32, ptr %vreg_loc_25, i32 0
  store i32 %6, ptr %9, align 4
  %10 = getelementptr i32, ptr %vreg_loc_25, i32 1
  store i32 %8, ptr %10, align 4
  call void @llvm.memcpy.p0.p0.i32(ptr %vreg_loc_28, ptr %vreg_loc_25, i32 8, i1 false)
  br label %BB1

BB1:                                              ; preds = %BB3
  %11 = getelementptr { i64 }, ptr %vreg_loc_28, i32 0, i32 0
  %12 = load i64, ptr %11, align 8
  %13 = insertvalue { i64 } undef, i64 %12, 0
  ret { i64 } %13
}

[ghost]

Tagging subscribers to this area: @SamMonoRT, @fanyang-mono
See info in area-owners.md if you want to be subscribed.

Issue Details

---

LLVM AOT failed to compile System.Private.CoreLib.dll on amd64 because of an issue related to X86Base.DivRem intrinsics

Both operands to a binary operator are not of the same type!
  %2 = shl i64 %1, i32 32
; Function Attrs: "?ɯ~???`?}?}?
                               ֚?"
define hidden monocc { i64 } @System_Runtime_Intrinsics_X86_X86Base_DivRem_uint_uint_uint(i32 %arg_lower, i32 %arg_upper, i32 %arg_divisor) #6 {
BB0:
  %vreg_loc_28 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  %vreg_loc_25 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  %vreg_loc_16 = alloca %"System.ValueTuple`2<uint, uint>", align 4
  br label %INIT_BB1

INIT_BB1:                                         ; preds = %BB0
  br label %INITED_BB2

INITED_BB2:                                       ; preds = %INIT_BB1
  br label %BB2

BB2:                                              ; preds = %INITED_BB2
  br label %BB3

BB3:                                              ; preds = %BB2
  %0 = zext i32 %arg_lower to i64
  %1 = zext i32 %arg_upper to i64
  %2 = shl i64 %1, i32 32
  %3 = or i64 %0, %2
  %4 = zext i32 %arg_divisor to i64
  %5 = udiv i64 %3, %4
  %6 = trunc i64 %5 to i32
  %7 = urem i64 %3, %4
  %8 = trunc i64 %7 to i32
  %9 = getelementptr i32, ptr %vreg_loc_25, i32 0
  store i32 %6, ptr %9, align 4
  %10 = getelementptr i32, ptr %vreg_loc_25, i32 1
  store i32 %8, ptr %10, align 4
  call void @llvm.memcpy.p0.p0.i32(ptr %vreg_loc_28, ptr %vreg_loc_25, i32 8, i1 false)
  br label %BB1

BB1:                                              ; preds = %BB3
  %11 = getelementptr { i64 }, ptr %vreg_loc_28, i32 0, i32 0
  %12 = load i64, ptr %11, align 8
  %13 = insertvalue { i64 } undef, i64 %12, 0
  ret { i64 } %13
}

Author:	fanyang-mono
Assignees:	-
Labels:	area-Codegen-LLVM-mono, area-Codegen-Intrinsics-mono
Milestone:	9.0.0

[SamMonoRT]

cc @jandupej - anything related to your recent changes?

[jandupej]

cc @jandupej - anything related to your recent changes?

It appears so. Looks like LLVM needs the bit count in the shift operator to be the same type as the shifted value. Still I'm not sure why the CI didn't catch this.