Failed analysis of index dominance

[leonardo-m]

rustc 1.50.0-nightly (f76ecd0 2020-12-15) on this code:

pub fn foo(data: &[u8], i: usize, j: usize) -> u8 {
    if i < data.len() && j <= i {
        data[j]
    } else {
        0
    }
}

Can't remove the array bound test (compiling even with aggressive optimizations):

foo:
    push    rax
    cmp     rdx, rsi
    jae     .LBB0_4
    cmp     rcx, rdx
    ja      .LBB0_4
    cmp     rcx, rsi
    jae     .LBB0_3
    mov     al, byte ptr [rdi + rcx]
    pop     rcx
    ret
.LBB0_4:
    xor     eax, eax
    pop     rcx
    ret
.LBB0_3:
    lea     rdx, [rip + .L__unnamed_1]
    mov     rdi, rcx
    call    qword ptr [rip + core::panicking::panic_bounds_check@GOTPCREL]
    ud2

This shows that value range analysis could be useful.

Godbolt: https://rust.godbolt.org/z/jPoY6Mnx6

[camelid]

I relabeled this as an enhancement proposal since to my understanding this isn't a bug.

[jrmuizel]

I filed corresponding gcc and llvm bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98357
https://bugs.llvm.org/show_bug.cgi?id=48544

[jrmuizel]

It looks like the new ConstraintElimination llvm pass should fix this.

[leonardo-m]

It looks like the new ConstraintElimination llvm pass should fix this.

That went better than expected. LLVM devs often deliver.

[jrmuizel]

I confirmed that: rustc --emit=asm -C passes=constraint-elimination -O test.rs with a rust built with llvm12 branch gives:

	.section	__TEXT,__text,regular,pure_instructions
	.macosx_version_min 10, 7
	.globl	__ZN4test3foo17hbf89db3e2fd7b5fcE
	.p2align	4, 0x90
__ZN4test3foo17hbf89db3e2fd7b5fcE:
	.cfi_startproc
	xorl	%eax, %eax
	cmpq	%rdx, %rsi
	jbe	LBB0_3
	cmpq	%rdx, %rcx
	ja	LBB0_3
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register %rbp
	movb	(%rdi,%rcx), %al
	popq	%rbp
LBB0_3:
	retq
	.cfi_endproc

[leonardo-m]

You could also test issue #80620 :-)

[leonardo-m]

Is -C passes=constraint-elimination part of -C opt-level=3?

[jrmuizel]

I would be surprised if it was, but it's probably worth adding.