Regression building python 3.11.3 on ppc64le

[tstellar]

I've run in to a regression building Python 3.11.3 on ppc64le. I bisected it and the regression as caused by 7d10213.

The problem is that one of the Python tests segfaults at this line: https://github.com/python/cpython/blob/f3909b8bc83675b7ab093dbc558e677558d8e718/Python/dtoa.c#L1660

I've attached the output of

clang -S -emit-llvm -Xclang -disable-llvm-optzns -c -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -Og -Wall -O2  -fexceptions -g -grecord-gcc-switches -pipe -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection  -D_GNU_SOURCE -fPIC -fwrapv   -O2  -fexceptions -g -grecord-gcc-switches -pipe -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection  -D_GNU_SOURCE -fPIC -fwrapv   -flto -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden  -I../Include/internal -IObjects -IInclude -IPython -I. -I../Include   -fPIC -DPy_BUILD_CORE -fno-strict-aliasing -o Python/dtoa.ll ../Python/dtoa.c

dtoa.ll.txt

@fhahn @nikic

[llvmbot]

@llvm/issue-subscribers-backend-powerpc

[fhahn]

I had a look but I wasn't able to check whether nuw nsw gets added correctly, as there is a large number of conditions involved. There's an extra nuw nsw added a sub that feeds the address computation at the location that segfaults.

@tstellar do you know if that's an issue on PPC only? I think the IR optimizations generate the same IR for different targets.

The relevant difference is

without 7d10213:

bb432:                                            ; preds = %bb425
  %sub427 = sub i32 15, %alloca16.0.lcssa622, !dbg !486
  %sub435 = sub i32 %add317624, %sub427, !dbg !487
  %sext437 = zext i32 %sub427 to i64
  %getelementptr438 = getelementptr [23 x double], ptr @global, i64 0, i64 %sext437, !dbg !489
  %load439 = load double, ptr %getelementptr438, align 8, !dbg !489
  %fmul441 = fmul double %load439, %load424, !dbg !490
  %sext443 = zext i32 %sub435 to i64
  %getelementptr444 = getelementptr [23 x double], ptr @global, i64 0, i64 %sext443, !dbg !491
  %load445 = load double, ptr %getelementptr444, align 8, !dbg !491
  %fmul447 = fmul double %fmul441, %load445, !dbg !492
  br label %bb1306, !dbg !493

With 7d10213

bb432:                                            ; preds = %bb425
  %sub427 = sub nuw nsw i32 15, %alloca16.0.lcssa622, !dbg !486
  %sub435 = sub nuw nsw i32 %add317624, %sub427, !dbg !487
  %sext437 = zext i32 %sub427 to i64
  %getelementptr438 = getelementptr [23 x double], ptr @global, i64 0, i64 %sext437, !dbg !489
  %load439 = load double, ptr %getelementptr438, align 8, !dbg !489
  %fmul441 = fmul double %load439, %load424, !dbg !490
  %sext443 = zext i32 %sub435 to i64
  %getelementptr444 = getelementptr [23 x double], ptr @global, i64 0, i64 %sext443, !dbg !491
  %load445 = load double, ptr %getelementptr444, align 8, !dbg !491
  %fmul447 = fmul double %fmul441, %load445, !dbg !492
  br label %bb1306, !dbg !493

This boils down to the following difference in the generated code:

without 7d10213:

.LBB2_103:                              # %bb432
	subfic 3, 18, 15
	addis 4, 2, global@toc@ha
	rldic 5, 3, 3, 29
	addi 4, 4, global@toc@l
	lfdx 0, 4, 5
	sub	3, 24, 3
	rldic 3, 3, 3, 29
	li 27, 0
	xsmuldp 0, 0, 1
	lfdx 1, 4, 3
	li 29, 0
	li 26, 0
	li 25, 0
	xsmuldp 1, 0, 1

With 7d10213

.LBB2_103:                              # %bb432
	addis 5, 2, global@toc@ha
	rldic 4, 19, 3, 29
	addi 5, 5, global@toc@l
	sub	4, 5, 4
	clrldi	3, 19, 32
	clrldi	6, 24, 32
	lfd 0, 120(4)
	add 3, 6, 3
	li 6, -15
	sldi 3, 3, 3
	rldic 4, 6, 3, 29
	add 3, 5, 3
	xsmuldp 0, 0, 1
	lfdx 1, 3, 4
	li 27, 0
	li 29, 0
	li 26, 0
	xsmuldp 1, 0, 1

Would it be possible for someone with PPC knowledge to check to rule out bad codegen in the PPC backend?

[tstellar]

@tstellar do you know if that's an issue on PPC only? I think the IR optimizations generate the same IR for different targets.

It is ppc64le only, the other targets I've tested (x86_64, aarch64, and s390x) do not crash.

[tstellar]

The difference in the assembly code is actually caused by the SeparateConstOffsetFromGEPPass IR pass which is only run on a few targets: aarch64, ppc64le, amdgpu, and nvptx.

Before:

  %273 = sub nuw nsw i32 15, %239, !dbg !486
  call void @llvm.dbg.value(metadata i32 %273, metadata !207, metadata !DIExpression()), !dbg !265
  %274 = sub nuw nsw i32 %238, %273, !dbg !487
  call void @llvm.dbg.value(metadata i32 %274, metadata !203, metadata !DIExpression()), !dbg !265
  %275 = zext i32 %273 to i64
  %276 = getelementptr [23 x double], ptr @tens, i64 0, i64 %275, !dbg !489
  %277 = load double, ptr %276, align 8, !dbg !489
  %278 = fmul double %277, %253, !dbg !490
  %279 = zext i32 %274 to i64
  %280 = getelementptr [23 x double], ptr @tens, i64 0, i64 %279, !dbg !491
  %281 = load double, ptr %280, align 8, !dbg !491
  %282 = fmul double %278, %281, !dbg !492
  br label %1153, !dbg !493

After:

  call void @llvm.dbg.value(metadata !DIArgList(i32 15, i32 %239), metadata !207, metadata !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg,
1, DW_OP_minus, DW_OP_stack_value)), !dbg !265
  call void @llvm.dbg.value(metadata !DIArgList(i32 %238, i32 15, i32 %239), metadata !203, metadata !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_
LLVM_arg, 1, DW_OP_LLVM_arg, 2, DW_OP_minus, DW_OP_minus, DW_OP_stack_value)), !dbg !265
  %273 = zext i32 %239 to i64
  %274 = sub i64 0, %273
  %275 = shl i64 %274, 3, !dbg !486
  %276 = getelementptr i8, ptr @tens, i64 %275, !dbg !486
  %277 = getelementptr i8, ptr %276, i64 120, !dbg !486
  %278 = load double, ptr %277, align 8, !dbg !486
  %279 = fmul double %278, %253, !dbg !488
  %280 = zext i32 %238 to i64
  %281 = zext i32 %239 to i64
  %282 = sub i64 0, %281
  %283 = sub i64 %280, %282
  %284 = shl i64 %283, 3, !dbg !489
  %285 = getelementptr i8, ptr @tens, i64 %284, !dbg !489
  %286 = getelementptr i8, ptr %285, i64 34359738248, !dbg !489
  %287 = load double, ptr %286, align 8, !dbg !489
  %288 = fmul double %279, %287, !dbg !490
  br label %1160, !dbg !491

[tstellar]

%286 = getelementptr i8, ptr %285, i64 34359738248, !dbg !489

This seems wrong.

[tstellar]

%286 = getelementptr i8, ptr %285, i64 34359738248, !dbg !489

This seems wrong.

It looks like a negative 32-bit number that was zero-extended to 64-bits and then shifted left by 3.

34359738248 is 0x7FFFFFF88

[tstellar]

Proposed fix: https://reviews.llvm.org/D149507