[PATCH] [X86] Convert esp-relative movs of function arguments to pushes, step 2

[Michael Kuperstein]

================
Comment at: lib/Target/X86/X86InstrInfo.cpp:1717-1718
@@ +1716,4 @@
+  // pseudo. This leaves us with a choice:
+  // 1) Look for the next ADJCALLSTACKUP, like the code below. This
+  // works, but certainly doesn't belong here.
+  // 2) Factor out the code that makes the decision on whether a function
----------------
rnk wrote:
> mkuper wrote:
> > rnk wrote:
> > > This is the best thing I can think of at the moment. =/
> > Too bad. :-\ 
> > 
> > So you think I should commit with this code as is?
> > This shouldn't be a huge problem in terms of compile-time (since I'm looking only until the next call, it can't go quadratic), but it's insanely ugly.
> Yeah, if we go with this MI pass approach to mov -> push conversion, then we'll have to keep this ADJCALLSTACKUP scan. We aren't going to move the callee cleanup stack adjustment onto the CALL instr without major changes.
This will have to happen regardless of the MI pass vs. DAG approach.

I mean, I still think doing it on the DAG is unfeasible, but even if we could do that, it wouldn't help. 
This code is used for the case where fi resolution needs to handle a a sequence where there is a fi reference between the call and the adjcallstackup, with callee cleanup for the call.
This is just a side effect of making canSimplifyCallFramePseudos return false.

================
Comment at: lib/Target/X86/X86InstrInfo.cpp:1745
@@ +1744,3 @@
+  // in call sequences
+  switch (MI->getOpcode()) {
+  default: 
----------------
rnk wrote:
> I wonder if it's possible for __readeflags() (pushf ;  pop %reg) or others to get folded into a call sequence. Probably not.
I don't see how it could happen.
In any case, we won't match either the pushf or the pop, so it should be ok.

http://reviews.llvm.org/D6789

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