Unfinished work and ideas related to register scavenger.
authorEvan Cheng <evan.cheng@apple.com>
Fri, 9 Mar 2007 19:34:51 +0000 (19:34 +0000)
committerEvan Cheng <evan.cheng@apple.com>
Fri, 9 Mar 2007 19:34:51 +0000 (19:34 +0000)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35047 91177308-0d34-0410-b5e6-96231b3b80d8

lib/Target/ARM/README.txt

index d831d63399a3d996d591b044c6c4e53cf5d853eb..f0f4d51b897a960632bffe1f8a32bdfeb6910a64 100644 (file)
@@ -427,6 +427,7 @@ http://www.inf.u-szeged.hu/gcc-arm/
 http://citeseer.ist.psu.edu/debus04linktime.html
 
 //===---------------------------------------------------------------------===//
+
 gcc generates smaller code for this function at -O2 or -Os:
 
 void foo(signed char* p) {
@@ -449,3 +450,16 @@ More seriously, there is a byte->word extend before
 each comparison, where there should be only one, and the condition codes
 are not remembered when the same two values are compared twice.
 
+//===---------------------------------------------------------------------===//
+
+More register scavenging work:
+
+1. Use the register scavenger to track frame index materialized into registers
+   (those that do not fit in addressing modes) to allow reuse in the same BB.
+2. Finish scavenging for Thumb.
+3. We know some spills and restores are unnecessary. The issue is once live
+   intervals are merged, they are not never split. So every def is spilled
+   and every use requires a restore if the register allocator decides the
+   resulting live interval is not assigned a physical register. It may be
+   possible (with the help of the scavenger) to turn some spill / restore
+   pairs into register copies.