summaryrefslogtreecommitdiff
path: root/lib/CodeGen/README.txt
diff options
context:
space:
mode:
authorDan Gohman <gohman@apple.com>2009-10-14 00:02:01 +0000
committerDan Gohman <gohman@apple.com>2009-10-14 00:02:01 +0000
commit9ba0e2ba87a5af3b863d9a5f6f620c9b7583d0f4 (patch)
treed04e2511f58f62a6cb69730c59330c92dfb6f4ed /lib/CodeGen/README.txt
parent363bbc011045a9f5710569cc191c520ec25b2907 (diff)
downloadllvm-9ba0e2ba87a5af3b863d9a5f6f620c9b7583d0f4.tar.gz
llvm-9ba0e2ba87a5af3b863d9a5f6f620c9b7583d0f4.tar.bz2
llvm-9ba0e2ba87a5af3b863d9a5f6f620c9b7583d0f4.tar.xz
This remat entry is basically done. There are hooks to allow targets
to remat non-load instructions as loads, and the remat code now uses the UnmodeledSideEffects flags, MachineMemOperands, and similar things to decide which instructions are valid for rematerialization. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84060 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/CodeGen/README.txt')
-rw-r--r--lib/CodeGen/README.txt38
1 files changed, 0 insertions, 38 deletions
diff --git a/lib/CodeGen/README.txt b/lib/CodeGen/README.txt
index 8e9ead7f66..b655dda411 100644
--- a/lib/CodeGen/README.txt
+++ b/lib/CodeGen/README.txt
@@ -30,44 +30,6 @@ It also increase the likelyhood the store may become dead.
//===---------------------------------------------------------------------===//
-I think we should have a "hasSideEffects" flag (which is automatically set for
-stuff that "isLoad" "isCall" etc), and the remat pass should eventually be able
-to remat any instruction that has no side effects, if it can handle it and if
-profitable.
-
-For now, I'd suggest having the remat stuff work like this:
-
-1. I need to spill/reload this thing.
-2. Check to see if it has side effects.
-3. Check to see if it is simple enough: e.g. it only has one register
-destination and no register input.
-4. If so, clone the instruction, do the xform, etc.
-
-Advantages of this are:
-
-1. the .td file describes the behavior of the instructions, not the way the
- algorithm should work.
-2. as remat gets smarter in the future, we shouldn't have to be changing the .td
- files.
-3. it is easier to explain what the flag means in the .td file, because you
- don't have to pull in the explanation of how the current remat algo works.
-
-Some potential added complexities:
-
-1. Some instructions have to be glued to it's predecessor or successor. All of
- the PC relative instructions and condition code setting instruction. We could
- mark them as hasSideEffects, but that's not quite right. PC relative loads
- from constantpools can be remat'ed, for example. But it requires more than
- just cloning the instruction. Some instructions can be remat'ed but it
- expands to more than one instruction. But allocator will have to make a
- decision.
-
-4. As stated in 3, not as simple as cloning in some cases. The target will have
- to decide how to remat it. For example, an ARM 2-piece constant generation
- instruction is remat'ed as a load from constantpool.
-
-//===---------------------------------------------------------------------===//
-
bb27 ...
...
%reg1037 = ADDri %reg1039, 1