From 2265b491931554eb59edfa1c2cfbda64b2e5de1b Mon Sep 17 00:00:00 2001 From: Evan Cheng Date: Fri, 9 Mar 2007 19:34:51 +0000 Subject: [PATCH] Unfinished work and ideas related to register scavenger. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35047 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Target/ARM/README.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/lib/Target/ARM/README.txt b/lib/Target/ARM/README.txt index d831d63399a..f0f4d51b897 100644 --- a/lib/Target/ARM/README.txt +++ b/lib/Target/ARM/README.txt @@ -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. -- 2.34.1