Missing optimization around __rust_alloc and unknown functions if panic=unwind #46515

RalfJung · 2017-12-05T10:40:37Z

The following code gets optimized as expected:

pub fn test() -> bool {
    let x = &*Box::new(0);
    let y = &*Box::new(0);
    
    if x as *const _ == y as *const _ {
        return true;
    }
    return false;
}

becomes

; example::test
; Function Attrs: nounwind uwtable
define zeroext i1 @example::test() unnamed_addr #0 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* @rust_eh_personality !dbg !18 {
  ret i1 false, !dbg !22
}

However, if I let the code call an unknown function instead of return, the optimization disappears:

pub fn test(f: fn()) {
    let x = &*Box::new(0);
    let y = &*Box::new(0);
    
    if x as *const _ == y as *const _ {
        f();
    }
}

becomes

; example::test
; Function Attrs: uwtable
define void @example::test(void ()* nocapture nonnull %f) unnamed_addr #1 personality i32 (i32, i32, i64, %"unwind::libunwind::_Unwind_Exception"*, %"unwind::libunwind::_Unwind_Context"*)* @rust_eh_personality !dbg !36 {
  %err.i.i.i10 = alloca %"core::mem::ManuallyDrop<alloc::allocator::AllocErr>", align 8
  %_5.i.i.i.i11 = alloca %"alloc::allocator::AllocErr", align 8
  %err.i.i.i = alloca %"core::mem::ManuallyDrop<alloc::allocator::AllocErr>", align 8
  %_5.i.i.i.i = alloca %"alloc::allocator::AllocErr", align 8
  %_9.sroa.9.i.i = alloca [16 x i8], align 8
  %_9.sroa.9.0.sroa_idx9.i.i = getelementptr inbounds [16 x i8], [16 x i8]* %_9.sroa.9.i.i, i64 0, i64 0, !dbg !38
  call void @llvm.lifetime.start(i64 16, i8* nonnull %_9.sroa.9.0.sroa_idx9.i.i), !dbg !38
  %0 = getelementptr inbounds %"core::mem::ManuallyDrop<alloc::allocator::AllocErr>", %"core::mem::ManuallyDrop<alloc::allocator::AllocErr>"* %err.i.i.i, i64 0, i32 0, i64 0, !dbg !48
  call void @llvm.lifetime.start(i64 24, i8* nonnull %0) #6, !dbg !48, !noalias !52
  %1 = call i8* @__rust_alloc(i64 4, i64 4, i8* nonnull %0) #6, !dbg !55, !noalias !52
  %2 = icmp eq i8* %1, null, !dbg !57
  br i1 %2, label �3.i.i.i, label %"_ZN35_$LT$alloc..boxed..Box$LT$T$GT$$GT$3new17he6f20be442f24a38E.exit", !dbg !61

[snip]

That seems wrong, why should the optimization stop kicking in? The corresponding C code does not have any problem:

#include <memory>

void test(void (*f)()) {
    auto x = std::make_unique<int>(0);
    auto y = std::make_unique<int>(0);

    if (&*x == &*y) {
        f();
    }
}

becomes

; Function Attrs: uwtable
define void @test(void (*)())(void ()* nocapture) local_unnamed_addr #0 personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) !dbg !1204 {
  tail call void @llvm.dbg.value(metadata void ()* %0, i64 0, metadata !1208, metadata !1211), !dbg !1212
  tail call void @llvm.dbg.value(metadata %"class.std::unique_ptr"* undef, i64 0, metadata !1209, metadata !1213), !dbg !1214
  tail call void @llvm.dbg.value(metadata %"class.std::unique_ptr"* undef, i64 0, metadata !1209, metadata !1213), !dbg !1214
  tail call void @llvm.dbg.value(metadata %"class.std::unique_ptr"* undef, i64 0, metadata !1210, metadata !1213), !dbg !1215
  tail call void @llvm.dbg.value(metadata %"class.std::unique_ptr"* undef, i64 0, metadata !1210, metadata !1213), !dbg !1215
  tail call void @llvm.dbg.value(metadata %"class.std::unique_ptr"* undef, i64 0, metadata !1209, metadata !1213), !dbg !1214
  ret void, !dbg !1216
}

(I briefly thought maybe unwinding is the problem, but C should have the same kind of unwinding here.)

The text was updated successfully, but these errors were encountered:

RalfJung · 2017-12-05T16:15:34Z

@eddyb suggested I try -C panic=abort, and indeed, that makes all the difference. However, the optimization is sound even with unwinding panics, so it should happen either way.

RalfJung · 2017-12-10T18:15:49Z

Aha! I think I got it. In the IR for the Rust program, the unwinding branch calls @_ZN4core3ptr13drop_in_place17h91409ca23b53ad07E with the noinline attribute. So LLVM does not look through this call at all, and (I guess) it considers the pointer passed to it escaped. The pointer equality folding only happens if the pointer does not get escaped, so LLVM can guarantee that all comparisons of this pointer are folded consistently.

So, to fix this, we'd have to remove this noinline -- at least for Box<T> where T does not itself implement Drop.

Box<T> drop glue is pretty simple and should not lead to blow-up problems. Moreover, not inlining it leads to LLVM pessimizing some pointer-based optimizations because it thinks the pointer passed to the drop glue could be escaped. Fixes rust-lang#46515. However, this is not a great fix -- the problem still exists for other smart pointers besides `Box`.

SimonSapin · 2018-04-01T17:02:53Z

CC @nox, @rust-lang/wg-codegen

nox · 2018-04-01T17:38:09Z

Could this be preventing other optimisations than pointer equality folding? Cc @rust-lang/compiler

nagisa · 2018-04-01T17:56:02Z

@nox definitely. My guess is that alias analysis is being overly conservative here and is declaring pointers to be MayAlias, rather than NoAlias, which what they definitely are. This will defeat many optimisations that check for aliasing (pretty much everything).

RalfJung · 2018-04-02T08:40:34Z

However, pointer equality optimizations and aliasing information are (AFAIK) mostly unrelated -- in particular, optimizing equalities based on noalias is incorrect:

int foo(restrict int *x, restrict int *y) {
  // The restrict will compile to noalias in LLVM. However, C does not let you
  // optimize the following unless both x and y are actually dereferenced.
  (x == y) ? 1 : 0
}

steveklabnik · 2020-01-20T17:47:54Z

Triage: this optimization still does not happen.

Revert "Auto merge of rust-lang#92419 - erikdesjardins:coldland, r=nagisa" Should fix (untested) rust-lang#94390 Reopens rust-lang#46515, rust-lang#87055 r? `@ehuss`

eddyb · 2022-03-28T02:58:18Z

@nagisa @erikdesjardins Oh no, #95338 ended up triggering LLVM to close this again.

…=nikic Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from ``@erikdesjardins`` (PR rust-lang#94823). This PR reapplies rust-lang#92419, which was reverted in rust-lang#94402 due to rust-lang#94390. Fixes rust-lang#46515, fixes rust-lang#87055. Update: fixes rust-lang#97217.

…ikic Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR rust-lang#94823). This PR reapplies rust-lang#92419, which was reverted in rust-lang#94402 due to rust-lang#94390. Fixes rust-lang#46515, fixes rust-lang#87055. Update: fixes rust-lang#97217.

Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR #94823). This PR reapplies rust-lang/rust#92419, which was reverted in rust-lang/rust#94402 due to rust-lang/rust#94390. Fixes rust-lang/rust#46515, fixes rust-lang/rust#87055. Update: fixes #97217.

kennytm added A-allocators Area: Custom and system allocators C-enhancement Category: An issue proposing an enhancement or a PR with one. I-slow Issue: Problems and improvements with respect to performance of generated code. labels Dec 5, 2017

RalfJung changed the title ~~Missing optimization around __rust_alloc and unknown functions~~ Missing optimization around __rust_alloc and unknown functions if panic=unwind Dec 5, 2017

RalfJung mentioned this issue Dec 10, 2017

Inline Box drop glue #46638

Closed

oxalica mentioned this issue Jul 11, 2021

Unable to optimize out branches in drop function in unwind landing pad #87055

Closed

erikdesjardins mentioned this issue Dec 29, 2021

Mark drop calls in landing pads cold instead of noinline #92419

Merged

bors closed this as completed in 4f49627 Jan 1, 2022

erikdesjardins mentioned this issue Feb 26, 2022

Revert "Auto merge of #92419 - erikdesjardins:coldland, r=nagisa" #94402

Merged

nagisa reopened this Feb 26, 2022

bors closed this as completed in da4a392 Mar 27, 2022

eddyb reopened this Mar 28, 2022

RalfJung mentioned this issue Apr 10, 2022

noalias on a Box doesn't seem to have an impact when compiling without -C panic=abort #95323

Open

erikdesjardins mentioned this issue Apr 24, 2022

Reapply: Mark drop calls in landing pads cold instead of noinline #94823

Closed

InnovativeInventor mentioned this issue Sep 21, 2022

Rebased: Mark drop calls in landing pads cold instead of noinline #102099

Merged

bors closed this as completed in 2e5a9dd Oct 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Missing optimization around __rust_alloc and unknown functions if panic=unwind #46515

Missing optimization around __rust_alloc and unknown functions if panic=unwind #46515

RalfJung commented Dec 5, 2017 •

edited

Loading

RalfJung commented Dec 5, 2017

RalfJung commented Dec 10, 2017 •

edited

Loading

SimonSapin commented Apr 1, 2018

nox commented Apr 1, 2018

nagisa commented Apr 1, 2018

RalfJung commented Apr 2, 2018

steveklabnik commented Jan 20, 2020

eddyb commented Mar 28, 2022

Missing optimization around __rust_alloc and unknown functions if panic=unwind #46515

Missing optimization around __rust_alloc and unknown functions if panic=unwind #46515

Comments

RalfJung commented Dec 5, 2017 • edited Loading

RalfJung commented Dec 5, 2017

RalfJung commented Dec 10, 2017 • edited Loading

SimonSapin commented Apr 1, 2018

nox commented Apr 1, 2018

nagisa commented Apr 1, 2018

RalfJung commented Apr 2, 2018

steveklabnik commented Jan 20, 2020

eddyb commented Mar 28, 2022

RalfJung commented Dec 5, 2017 •

edited

Loading

RalfJung commented Dec 10, 2017 •

edited

Loading