[LLVMdev] [PROPOSAL] Improve uses of LEA on Atom
Nowicki, Tyler
tyler.nowicki at intel.com
Fri Sep 28 08:36:24 PDT 2012
Hi,
Here is an update on our proposal to improve the uses of LEA on Atom processors.
1. Disable current generation of LEAs
Due to a 3 cycle stall between the ALU and the AGU any address generation done using math instruction will cause a stall on loads and stores which are within 3 cycles of the address generation. Consequently, the heuristics for using LEAs efficiently must know how many cycles pass between the address generation and its use. However, currently LEAs are inserted before this information is known (ie before register allocation). Part of the attached patch disables the current generation of LEAs.
2. Identify loads and stores in a X86PassConfig::addPreEmitPass() pass
We will use an addPreEmitPass pass, similar to the VZeroUpper pass. For each load/store found we will identify its address and index, and examine previous instructions to identify where they are being generated to identify opportunities for LEAs.
3. Replacing instructions with LEAs
Instructions such as add/{reg,imm}, add/{reg,imm}+shift/{reg,imm}, or sub/imm, will be replaced with a single LEA. This will potentially reduce the number of registers in use, however, because this pass follows register allocation it will not affect instruction scheduling.
Attached is an incomplete patch with test cases that disables current LEA generation and includes an empty pre-emit pass that will contain the LEA selection heuristics.
Any feedback you may have on this updated plan is welcome.
Sincerely,
Tyler Nowicki
Intel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120928/cfbf8bf3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UpdatedProposalPatch-svn.patch
Type: application/octet-stream
Size: 19061 bytes
Desc: UpdatedProposalPatch-svn.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120928/cfbf8bf3/attachment.obj>
More information about the llvm-dev
mailing list