[PATCH] [Statepoints] Reuse stack slots for assignment idioms

[Igor Laevsky]

================
Comment at: lib/CodeGen/SelectionDAG/StatepointLowering.cpp:422-424
@@ -420,1 +421,5 @@
 
+  // Now spill the value.  When we have multiple values which map the same
+  // stack slot this may result in redundant spills, but we can generally rely
+  // on the backend to clean these up for us and don't need to be fancy here.
+  
----------------
igor-laevsky wrote:
> Are you certain about this? I do remember experimenting with this approach, but I was seeing quite the opposite picture - almost no redundant stores were removed. But actually it was quite a while ago and I didn't dig to deep into this, maybe my code had some simple mistake. I will try to run few of my old tests on your code tomorrow.
Yes, as I suspected there is little llvm can do about this redundant stores. Actually from quick glance at the code I don't see place in llvm where it removes dead stores in machine code. There is small function in StackSlotColoring, but it is very limited. MachineCSE and RemoveDeadInstructions explicitly discard all mayStore values.

I am wondering is there any good reason why there is no dead store elimination for the machine code? In theory it should not be very hard to implement.

================
Comment at: test/CodeGen/X86/statepoint-stack-usage.ll:137
@@ +136,3 @@
+; the original value is only live for the update.
+define i32 addrspace(1)* @test5(i32 addrspace(1)* %a) gc "statepoint-example" {
+; CHECK-LABEL: test5
----------------
This actually passes even without your changes. Maybe add some additional oops to the second statepoint, so that by default we would assign different slots for a1 and a1_derived.

http://reviews.llvm.org/D10402

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/