LLVM miscompiles some vector instructions for MIPS

[LemonBoy]

EDIT:: Here are the reduced and failing test cases.

; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "foo"
target datalayout = "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mipsel-unknown-linux-none"

define dso_local fastcc void @hash(<4 x i9>) unnamed_addr #0 {
Entry:
  store <4 x i9> %0, <4 x i9>* undef, align 8
  unreachable
}

attributes #0 = { "no-frame-pointer-elim-non-leaf" }

!llvm.module.flags = !{!0}

!0 = !{i32 2, !"Dwarf Version", i32 4}

; ModuleID = 'bugpoint-reduced-simplified.bc'
source_filename = "foo"
target datalayout = "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mipsel-unknown-linux-none"

; Function Attrs: nobuiltin nounwind
define void @entry() #0 {
Entry:
  %a = alloca <3 x i9>, align 8
  store <3 x i9> <i9 8, i9 16, i9 24>, <3 x i9>* %a, align 8
  %0 = load <3 x i9>, <3 x i9>* %a, align 8
  call fastcc void @hash(<3 x i9> %0)
  ret void
}

; Function Attrs: nobuiltin nounwind
define internal fastcc void @hash(<3 x i9>) unnamed_addr #0 {
Entry:
  %array = alloca [3 x i9], align 2
  %x = alloca <3 x i9>, align 8
  store <3 x i9> %0, <3 x i9>* %x, align 8
  %1 = load <3 x i9>, <3 x i9>* %x, align 8
  %2 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 0
  %3 = extractelement <3 x i9> %1, i32 0
  store i9 %3, i9* %2
  %4 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 1
  %5 = extractelement <3 x i9> %1, i32 1
  store i9 %5, i9* %4
  %6 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 2
  %7 = extractelement <3 x i9> %1, i32 2
  store i9 %7, i9* %6
  %8 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 0
  %9 = load i9, i9* %8, align 2
  %10 = icmp ne i9 %9, 8
  br i1 %10, label %Then, label %Else

Then:                                             ; preds = %Entry
  call void @llvm.debugtrap()
  br label %EndIf

Else:                                             ; preds = %Entry
  br label %EndIf

EndIf:                                            ; preds = %Else, %Then
  %11 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 1
  %12 = load i9, i9* %11, align 2
  %13 = icmp ne i9 %12, 16
  br i1 %13, label %Then1, label %Else2

Then1:                                            ; preds = %EndIf
  call void @llvm.debugtrap()
  br label %EndIf3

Else2:                                            ; preds = %EndIf
  br label %EndIf3

EndIf3:                                           ; preds = %Else2, %Then1
  %14 = getelementptr inbounds [3 x i9], [3 x i9]* %array, i32 0, i32 2
  %15 = load i9, i9* %14, align 2
  %16 = icmp ne i9 %15, 24
  br i1 %16, label %Then4, label %Else5

Then4:                                            ; preds = %EndIf3
  call void @llvm.debugtrap()
  br label %EndIf6

Else5:                                            ; preds = %EndIf3
  br label %EndIf6

EndIf6:                                           ; preds = %Else5, %Then4
  ret void
}

; Function Attrs: nounwind
declare void @llvm.debugtrap() #1

attributes #0 = { nobuiltin nounwind "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" }
attributes #1 = { nounwind }

!llvm.module.flags = !{!0, !1}
!llvm.dbg.cu = !{!2}

!0 = !{i32 2, !"Debug Info Version", i32 3}
!1 = !{i32 2, !"Dwarf Version", i32 4}
!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "zig 0.5.0", isOptimized: false, runtimeVersion: 0, emissionKind: NoDebug, enums: !4)
!3 = !DIFile(filename: "foo", directory: "/tmp")
!4 = !{}

[andrewrk]

Does it matter the target?

[andrewrk]

Before I file an upstream bug report, can you confirm this is what you're seeing (using trunk on godbolt)?

https://godbolt.org/z/9P-rlQ

.LCPI2_0:
        .long   1                       # 0x1
        .long   2                       # 0x2
        .long   3                       # 0x3
        .long   5                       # 0x5
main:                                   # @main
        push    rax
        movaps  xmm0, xmmword ptr [rip + .LCPI2_0] # xmm0 = [1,2,3,5]
        call    k

The only part I'm confused about is why its' doing rip +. Seems like it should just want the address of .LCPI2_0 directly. However I'm not confident about that because when I change all the i31 to i32 the output is the same:

.LCPI2_0:
        .long   1                       # 0x1
        .long   2                       # 0x2
        .long   3                       # 0x3
        .long   5                       # 0x5
main:                                   # @main
        push    rax
        movaps  xmm0, xmmword ptr [rip + .LCPI2_0] # xmm0 = [1,2,3,5]
        call    k

[LemonBoy]

Does it matter the target?

I'm a dumbass and forgot to say this is for the mipsel-linux-none triple.

[andrewrk]

https://godbolt.org/z/BMfQkn

main:                                   # @main
        addiu   $sp, $sp, -8
        sw      $ra, 4($sp)             # 4-byte Folded Spill
        addiu   $4, $zero, 1
        addiu   $5, $zero, 2
        addiu   $6, $zero, 3
        addiu   $7, $zero, 5
        jal     k

For the sake of improving the chances of getting attention on the bug report, walk me through the issue here?

[LemonBoy]

Oh well, the very same llvm IR that compiles just fine here generates complete garbage if you compile this snippet:

pub fn k(key: var) void {
    const Key = @typeOf(key);
    switch (@typeInfo(Key)) {
        .Vector => |info| {
            const array: [info.len]info.child = key;
            for (array) |x| {
                @import("std").debug.warn("{}\n", x);
            }
        },
        else => unreachable,
    }
}
pub fn main() void {
    const d: @Vector(4, u31) = [_]u31{ 1, 2, 3, 5 };
    k(d);
}

The generated assembly is:

	.p2align	2
	.type	main,@function
	.set	nomicromips
	.set	nomips16
	.ent	main
main:
$tmp4412:
.set $func_begin420, ($tmp4412)
	.file	44 "/tmp/foo.zig"
	.loc	44 13 0
	.cfi_startproc
	.frame	$fp,8,$ra
	.mask 	0xc0000000,-4
	.fmask	0x00000000,0
	.set	noreorder
	.set	nomacro
	.set	noat
	addiu	$sp, $sp, -8
	.cfi_def_cfa_offset 8
	sw	$ra, 4($sp)
	sw	$fp, 0($sp)
	.cfi_offset 31, -4
	.cfi_offset 30, -8
	move	$fp, $sp
	.cfi_def_cfa_register 30
	addiu	$4, $zero, 1
	addiu	$5, $zero, 2
	addiu	$6, $zero, 3
$tmp4413:
	.loc	44 15 6 prologue_end
	jal	k
	nop
	.loc	44 13 20
	move	$sp, $fp
	lw	$fp, 0($sp)
	lw	$ra, 4($sp)
	addiu	$sp, $sp, 8
	jr	$ra
	nop
$tmp4414:
	.set	at
	.set	macro
	.set	reorder
	.end	main
$func_end420:
	.size	main, ($func_end420)-main
	.cfi_endproc

	.p2align	2
	.type	k,@function
	.set	nomicromips
	.set	nomips16
	.ent	k
k:
$tmp4415:
.set $func_begin421, ($tmp4415)
	.loc	44 0 0
	.cfi_startproc
	.frame	$fp,64,$ra
	.mask 	0xc0000000,-4
	.fmask	0x00000000,0
	.set	noreorder
	.set	nomacro
	.set	noat
	addiu	$sp, $sp, -64
	.cfi_def_cfa_offset 64
	sw	$ra, 60($sp)
	sw	$fp, 56($sp)
	.cfi_offset 31, -4
	.cfi_offset 30, -8
	move	$fp, $sp
	.cfi_def_cfa_register 30
	addiu	$1, $zero, -16
	and	$sp, $sp, $1
	sw	$zero, 28($sp)
	sw	$zero, 24($sp)
	sw	$zero, 20($sp)
	sw	$zero, 16($sp)
$tmp4416:
	.loc	44 5 49 prologue_end
	lwl	$5, 29($sp)
	lwr	$5, 26($sp)
	lwl	$6, 26($sp)
	lwr	$6, 23($sp)
	lwl	$7, 22($sp)
	lwr	$7, 19($sp)
	lw	$8, 16($sp)
	sw	$8, 40($sp)
	sw	$7, 44($sp)
	sw	$6, 48($sp)
	sw	$5, 52($sp)
	.loc	44 6 13
	sw	$zero, 36($sp)
	sw	$1, 12($sp)
	j	$BB421_1
	nop
$BB421_1:
	lw	$1, 36($sp)
	sltiu	$2, $1, 4
	sw	$1, 8($sp)
	beqz	$2, $BB421_4
	nop
	j	$BB421_3
	nop
$BB421_3:
	lw	$1, 8($sp)
	sll	$2, $1, 2
	addiu	$3, $sp, 40
	addu	$2, $3, $2
$tmp4417:
	.loc	44 7 51
	lw	$4, 0($2)
	.loc	44 7 42 is_stmt 0
	jal	std.debug.warn.153
	nop
$tmp4418:
	.loc	44 6 13 is_stmt 1
	lw	$1, 8($sp)
	addiu	$2, $1, 1
	sw	$2, 36($sp)
	j	$BB421_1
	nop
$tmp4419:
$BB421_4:
	.loc	44 1 25
	move	$sp, $fp
	lw	$fp, 56($sp)
	lw	$ra, 60($sp)
	addiu	$sp, $sp, 64
	jr	$ra
	nop
$tmp4420:
	.set	at
	.set	macro
	.set	reorder
	.end	k
$func_end421:
	.size	k, ($func_end421)-k
	.cfi_endproc

I have no clue about why the problem goes away if you shorten the LLVM IR.

[andrewrk]

OK thanks. The next step here will be creating a reduction

[LemonBoy]

@andrewrk I've reduced the test cases as much as I could (or, better, as much as bugpoint managed to reduce them).

[andrewrk]

Thanks @LemonBoy, I'll create the upstream bug report and link it here.

[LemonBoy]

One more failing case, this one doesn't trigger any assertion but produces nonsensical code:

; ModuleID = 'foo'
source_filename = "foo"
target datalayout = "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mipsel-unknown-unknown-eabi"

; Function Attrs: nobuiltin nounwind
define void @entry() {
Entry:
  %x2 = alloca <4 x i1>, align 4
  %x1 = alloca [4 x i1], align 1
  store <4 x i1> <i1 false, i1 true, i1 false, i1 true>, <4 x i1>* %x2, align 4
  %0 = load <4 x i1>, <4 x i1>* %x2, align 4
  %1 = getelementptr inbounds [4 x i1], [4 x i1]* %x1, i32 0, i32 0
  %2 = extractelement <4 x i1> %0, i32 0
  store i1 %2, i1* %1
  %3 = getelementptr inbounds [4 x i1], [4 x i1]* %x1, i32 0, i32 1
  %4 = extractelement <4 x i1> %0, i32 1
  store i1 %4, i1* %3
  %5 = getelementptr inbounds [4 x i1], [4 x i1]* %x1, i32 0, i32 2
  %6 = extractelement <4 x i1> %0, i32 2
  store i1 %6, i1* %5
  %7 = getelementptr inbounds [4 x i1], [4 x i1]* %x1, i32 0, i32 3
  %8 = extractelement <4 x i1> %0, i32 3
  store i1 %8, i1* %7
  %9 = getelementptr inbounds [4 x i1], [4 x i1]* %x1, i32 0, i32 3
  %10 = load i1, i1* %9, align 1
  %11 = icmp ne i1 %10, true
  br i1 %11, label %Then, label %Else

Then:                                             ; preds = %Entry
  call void @llvm.debugtrap()
  br label %EndIf

Else:                                             ; preds = %Entry
  br label %EndIf

EndIf:                                            ; preds = %Else, %Then
  ret void
}

; Function Attrs: nounwind
declare void @llvm.debugtrap()

It generates this ASM:

	addiu	$1, $zero, 10
	sb	$1, 4($sp)
	lbu	$1, 4($sp)
	andi	$1, $1, 1
	sb	$1, 0($sp)
	sb	$1, 1($sp)
	sb	$1, 2($sp)
	sb	$1, 3($sp)
	lbu	$1, 3($sp)

All the vector elements get the same value, the LSB in the packed vector (10 => 1010).