[ATOM] Memory form of call optimization

[Michael Liao]

This patch could be simplified by directly not selecting CALL32m or
CALL64m by the following patch by removing the unnecessary
copy-from-reg/copy-to-reg sequence.

Yours
- Michael

--- a/lib/Target/X86/X86InstrControl.td
+++ b/lib/Target/X86/X86InstrControl.td
@@ -158,7 +158,7 @@ let isCall = 1 in
                          Requires<[In32BitMode]>;
     def CALL32m     : I<0xFF, MRM2m, (outs), (ins i32mem:$dst),
                         "call{l}\t{*}$dst", [(X86call (loadi32 addr:
$dst))], IIC_CALL_MEM>,
-                        Requires<[In32BitMode]>;
+                        Requires<[In32BitMode,FavorIndirectMemCall]>;
 
     def FARCALL16i  : Iseg16<0x9A, RawFrmImm16, (outs),
                              (ins i16imm:$off, i16imm:$seg),
@@ -231,7 +231,7 @@ let isCall = 1, Uses = [RSP] in {
   def CALL64m       : I<0xFF, MRM2m, (outs), (ins i64mem:$dst),
                         "call{q}\t{*}$dst", [(X86call (loadi64 addr:
$dst))],
                         IIC_CALL_MEM>,
-                      Requires<[In64BitMode]>;
+                      Requires<[In64BitMode,FavorIndirectMemCall]>;
 
   def FARCALL64   : RI<0xFF, MRM3m, (outs), (ins opaque80mem:$dst),
                        "lcall{q}\t{*}$dst", [], IIC_CALL_FAR_MEM>;
diff --git a/lib/Target/X86/X86InstrInfo.td
b/lib/Target/X86/X86InstrInfo.td
index 39165e2..840fac4 100644
--- a/lib/Target/X86/X86InstrInfo.td
+++ b/lib/Target/X86/X86InstrInfo.td
@@ -626,6 +626,7 @@ def OptForSize   : Predicate<"OptForSize">;
 def OptForSpeed  : Predicate<"!OptForSize">;
 def FastBTMem    : Predicate<"!Subtarget->isBTMemSlow()">;
 def CallImmAddr  :
Predicate<"Subtarget->IsLegalToCallImmediateAddr(TM)">;
+def FavorIndirectMemCall : Predicate<"!Subtarget->callRegIndirect()">;
 
 //===----------------------------------------------------------------------===//
 // X86 Instruction Format Definitions.



On Mon, 2013-03-25 at 15:38 -0700, Evan Cheng wrote:
> LGTM
> 
> 
> Evan
> On Mar 25, 2013, at 3:22 PM, "Murali, Sriram"
> <sriram.murali at intel.com> wrote:
> 
> > Hi Evan,
> > Good catch.
> > I initially added that check specific to 32 bit code, to address an
> > anomaly that I found. But it was wrong, and I reverted the check. I
> > sent the incorrect patch by mistake. Here is the correct version of
> > the patch. Also added a one more check in the lit test.
> >  
> > Sorry for the confusion.
> >  
> > Please have a look at it J
> >  
> > Thanks
> > Sriram
> >  
> >  
> > From: Evan Cheng [mailto:evan.cheng at apple.com] 
> > Sent: Monday, March 25, 2013 5:31 PM
> > To: Murali, Sriram
> > Cc: llvm-commits at cs.uiuc.edu
> > Subject: Re: [ATOM] Memory form of call optimization
> >  
> > I'm a bit confused by the comment:
> > +  // Do the optimization only if the Subtarget is 64 bit where, 
> >  
> > However, I see you have added tests which checks for 32-bit code
> > sequence. Does the patch impact 32-bit?
> >  
> > Evan
> >  
> > On Mar 25, 2013, at 12:17 PM, "Murali, Sriram"
> > <sriram.murali at intel.com> wrote:
> > 
> > 
> > 
> > Hi, I am attaching the original patch, as well as an additional
> > patch to address the generation of memory forms of call when there
> > is a “folded reload” by the way register allocator handles unspill
> > of the spilled registers to the stack. The second patch is bigger
> > because of the lit tests added, while the actual modification to the
> > llvm source is very small. The lit test is huge, because it is hard
> > to create a scenario with spilling and unspilling of registers.
> >  
> > Please review.
> > 
> > Thanks
> > Sriram
> >  
> > From: Murali, Sriram 
> > Sent: Tuesday, March 19, 2013 6:40 PM
> > To: llvm-commits at cs.uiuc.edu
> > Subject: [ATOM] Memory form of call optimization
> >  
> > Hi,
> >  
> > Memory form of call is micro-coded on Atom architecture. We can
> > avoid this by loading the function pointer prior to the call. Memory
> > form of call is identified in LLVM by the sequence of instructions
> > chained to the call that obtains the function pointer. Memory forms
> > of call are produced by a sequence of two loads in 32-bit mode or a
> > single load in 64-bit mode preceding the call instruction . We would
> > like to commit this work and add additional sequences later.
> >  
> > Please review.
> >  
> > Thanks,
> > Sriram
> >  
> > --
> > Sriram Murali
> > SSG/DPD/ECDL/DMP
> > +1 (519) 772 – 2579
> >  
> > <CALL_REG_INDIRECT.patch><CALL_REG_INDIRECT_FOLDED_RELOAD.patch>_______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >  
> > <CALL_REG_INDIRECT.patch>
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits