[ATOM] Memory form of call optimization

[Murali, Sriram]

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 :)

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<mailto: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<mailto: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<mailto: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/4b0c04e0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CALL_REG_INDIRECT.patch
Type: application/octet-stream
Size: 5383 bytes
Desc: CALL_REG_INDIRECT.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130325/4b0c04e0/attachment.obj>