Moving out of locals still calls drop glue

[alexcrichton]

When not moving out of a local, you get the following codegen:

struct Node {
    right: Option<~Node>
}

#[inline(never)]
fn foo() -> Option<~Node>{
    None
}

fn main() {}

; Function Attrs: noinline nounwind uwtable
define void @"_ZN3foo15_e8578a1b12212b7_0$x2e0E"(%"enum.std::option::Option<~Node>[#1]"* nocapture, { i64, %tydesc*, i8*, i8*, i8 }* nocapture) #0 {
"function top level":
  %2 = getelementptr inbounds %"enum.std::option::Option<~Node>[#1]"* %0, i64 0, i32 0
  store %struct.Node* null, %struct.Node** %2, align 8
  ret void
}

Which is pretty much expected. When you do move out of a local, however, you get this codegen:

struct Node {
    right: Option<~Node>
}

#[inline(never)]
fn foo() -> Option<~Node>{
    let slot = None;
    slot
}

fn main() {}

; Function Attrs: noinline uwtable
define void @"_ZN3foo15_e8578a1b12212b7_0$x2e0E"(%"enum.std::option::Option<~Node>[#1]"* nocapture, { i64, %tydesc*, i8*, i8*, i8 }* nocapture) #0 {
"function top level":
  %slot = alloca %"enum.std::option::Option<~Node>[#1]", align 8
  %2 = getelementptr inbounds %"enum.std::option::Option<~Node>[#1]"* %slot, i64 0, i32 0
  %3 = getelementptr inbounds %"enum.std::option::Option<~Node>[#1]"* %0, i64 0, i32 0
  store %struct.Node* null, %struct.Node** %3, align 8
  store %struct.Node* null, %struct.Node** %2, align 8
  call fastcc void @"_ZN35std..option..Option$LT$$UP$Node$GT$17_2c255f6811918cb214glue_drop_3590E"(%"enum.std::option::Option<~Node>[#1]"* %slot)
  ret void
}

When moving out of a local, I wouldn't expect the drop glue to be generated at all. It will never have anything to drop, anyway, and it seems like it's always just a no-op (and expensive if you're running it millions of times). I've got a splay-tree implementation and currently drop glue in a function which never drops anything is the highest in the profiles which worries me.

cc @dotdash

[alexcrichton]

Oh, I should also mention that I generated the IR with -O

[graydon]

I'm on phone, but: see the llvm codegen bug, linked bug on move semantics. Also ask @bblum

[alexcrichton]

Ah yes, I'm going to close this as a dup of #5016