[ATOM] Memory form of call optimization

[Evan Cheng]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130325/ab704247/attachment.html>