Skip to content

precondition_check functions can survive MonoReachable #131578

Open
@saethlin

Description

@saethlin

The motivating example is this: https://rust.godbolt.org/z/dGe6EMrEz, the IR of the function at the top which is IndexRange as SliceIndex<[T]>>::get_unchecked_mut contains a precondition check. The fact that the call is in a block without any predecessors does not make this unimportant, #121421 is not working here.

The MIR for the function in question looks like this:

bb0: {   
    _3 = UbChecks();
    switchInt(copy _3) -> [0: bb3, otherwise: bb1];
}

bb1: {   
    <snip>
    _4 = <IndexRange as SliceIndex<[T]>>::get_unchecked_mut::precondition_check(move _5, move _6) -> [return: bb2, unwind unreachable];
}

bb2: {   
    <snip>
    goto -> bb4; 
}

bb3: {   
    <snip>
    switchInt(copy _3) -> [0: bb5, otherwise: bb4];
}

bb4: {   
    _10 = num::<impl usize>::unchecked_sub::precondition_check(copy _9, copy _7) -> [return: bb5, unwind unreachable];
}

bb5: {
    <snip>
    return;
}

The MIR optimization pipeline has helpfully hoisted the assignment of UbChecks() to a local then consulted that twice. But mono-reachable traversal onlky understands that the very specific pattern in bb0, and does not figure out that bb3 is also a switch on a constant that it could handle.

Post-mono GVN is really the way out of this. We'd love to have switchInt(const true) or switchInt(const false) in the MIR. Codegen could figure that out easily. I'm going to see what it takes to paper another hack over this instead, on the off-chance that it is highly effective and easy to do.

Metadata

Metadata

Assignees

Labels

A-codegenArea: Code generationC-bugCategory: This is a bug.C-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions