From 603f3094eb58fb3be6ce3ba9c7eff8723480baa9 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. llvm-svn: 35047 --- llvm/lib/Target/ARM/README.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/llvm/lib/Target/ARM/README.txt b/llvm/lib/Target/ARM/README.txt index d831d63399a3..f0f4d51b897a 100644 --- a/llvm/lib/Target/ARM/README.txt +++ b/llvm/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.