[llvm-commits] [PATCH][Review Please] Optimize ARM Position Independent Code Generation

[Yin Ma]

Hi Evan,

 

This patch addressed the problem I submitted before.  The default

Option has been set to off. A segment of redundant elimination code

has been removed. I will commit the new redundant elimination later

after it becomes available. 

 

Thanks,

 

                             Yin 

 

 

 

From: Evan Cheng [mailto:evan.cheng at apple.com] 
Sent: Wednesday, August 01, 2012 11:12 AM
To: Yin Ma
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH][Review Please] Optimize ARM Position
Independent Code Generation

 

Thanks. This looks like a good change to ELF codegen. I am ok with the isel
change.

 

However, I'm not ok with pre-ra load / store optimizer change. It's the
wrong place to do it. MachineCSE should be eliminating the unnecessary PIC
instructions. You might want to look at Darwin codegen and how it plays with
MachineCSE.

 

Evan

 

On Aug 1, 2012, at 10:24 AM, Yin Ma <yinma at codeaurora.org> wrote:





Hi Evan,

 

The attached pdf contains an example of this change. It can result

In code size reduction for most of PIC enabled programs.

 

Thanks,

 

                              Yin

 

From: Evan Cheng [mailto:evan.cheng@ <http://apple.com> apple.com] 
Sent: Tuesday, July 31, 2012 5:48 PM
To: Yin Ma
Cc:  <mailto:llvm-commits at cs.uiuc.edu> llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH][Review Please] Optimize ARM Position
Independent Code Generation

 

Hi Yin,

 

Can you provide some assembly code so we can understand what you are trying
to do?

 

Thanks,

 

Evan

 

On Jul 30, 2012, at 10:55 AM, Yin Ma < <mailto:yinma at codeaurora.org>
yinma at codeaurora.org> wrote:






Hi

Currently LLVM ARM backend is still using the x86 way to generate position
independent code. The algorithm retrieves the pointer of global offset table
at first. However, GCC has been using the label relative offset to computer
position independent code. The GCC way results smaller code size in ARM
architecture. This patch is to implement GCC way to generate position
independent code.

In the attachment.
pic.diff is the code patch
the rest of four files are the test validation results before and after code
changed

Please give a review

 

Thanks,

 

                    Yin

<report.simple.new.txt><report.simple.org.txt><cross.new><
<http://cross.org>
cross.org><pic.diff>_______________________________________________
llvm-commits mailing list
 <mailto:llvm-commits at cs.uiuc.edu> llvm-commits at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

 

<pic.pdf>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.simple.new.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.simple.org.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cross.new
Type: application/octet-stream
Size: 3081 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cross.org
Type: application/octet-stream
Size: 3049 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic2.diff
Type: application/octet-stream
Size: 13879 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120823/2b7dcd41/attachment-0002.obj>