xref: /aosp_15_r20/external/llvm/docs/HistoricalNotes/2003-06-26-Reoptimizer2.txt (revision 9880d6810fe72a1726cb53787c6711e909410d58)
1*9880d681SAndroid Build Coastguard WorkerThu Jun 26 14:43:04 CDT 2003
2*9880d681SAndroid Build Coastguard Worker
3*9880d681SAndroid Build Coastguard WorkerInformation about BinInterface
4*9880d681SAndroid Build Coastguard Worker------------------------------
5*9880d681SAndroid Build Coastguard Worker
6*9880d681SAndroid Build Coastguard WorkerTake in a set of instructions with some particular register
7*9880d681SAndroid Build Coastguard Workerallocation. It allows you to add, modify, or delete some instructions,
8*9880d681SAndroid Build Coastguard Workerin SSA form (kind of like LLVM's MachineInstrs.) Then re-allocate
9*9880d681SAndroid Build Coastguard Workerregisters. It assumes that the transformations you are doing are safe.
10*9880d681SAndroid Build Coastguard WorkerIt does not update the mapping information or the LLVM representation
11*9880d681SAndroid Build Coastguard Workerfor the modified trace (so it would not, for instance, support
12*9880d681SAndroid Build Coastguard Workermultiple optimization passes; passes have to be aware of and update
13*9880d681SAndroid Build Coastguard Workermanually the mapping information.)
14*9880d681SAndroid Build Coastguard Worker
15*9880d681SAndroid Build Coastguard WorkerThe way you use it is you take the original code and provide it to
16*9880d681SAndroid Build Coastguard WorkerBinInterface; then you do optimizations to it, then you put it in the
17*9880d681SAndroid Build Coastguard Workertrace cache.
18*9880d681SAndroid Build Coastguard Worker
19*9880d681SAndroid Build Coastguard WorkerThe BinInterface tries to find live-outs for traces so that it can do
20*9880d681SAndroid Build Coastguard Workerregister allocation on just the trace, and stitch the trace back into
21*9880d681SAndroid Build Coastguard Workerthe original code. It has to preserve the live-ins and live-outs when
22*9880d681SAndroid Build Coastguard Workerit does its register allocation.  (On exits from the trace we have
23*9880d681SAndroid Build Coastguard Workerepilogues that copy live-outs back into the right registers, but
24*9880d681SAndroid Build Coastguard Workerlive-ins have to be in the right registers.)
25*9880d681SAndroid Build Coastguard Worker
26*9880d681SAndroid Build Coastguard Worker
27*9880d681SAndroid Build Coastguard WorkerLimitations of BinInterface
28*9880d681SAndroid Build Coastguard Worker---------------------------
29*9880d681SAndroid Build Coastguard Worker
30*9880d681SAndroid Build Coastguard WorkerIt does copy insertions for PHIs, which it infers from the machine
31*9880d681SAndroid Build Coastguard Workercode. The mapping info inserted by LLC is not sufficient to determine
32*9880d681SAndroid Build Coastguard Workerthe PHIs.
33*9880d681SAndroid Build Coastguard Worker
34*9880d681SAndroid Build Coastguard WorkerIt does not handle integer or floating-point condition codes and it
35*9880d681SAndroid Build Coastguard Workerdoes not handle floating-point register allocation.
36*9880d681SAndroid Build Coastguard Worker
37*9880d681SAndroid Build Coastguard WorkerIt is not aggressively able to use lots of registers.
38*9880d681SAndroid Build Coastguard Worker
39*9880d681SAndroid Build Coastguard WorkerThere is a problem with alloca: we cannot find our spill space for
40*9880d681SAndroid Build Coastguard Workerspilling registers, normally allocated on the stack, if the trace
41*9880d681SAndroid Build Coastguard Workerfollows an alloca(). What might be an acceptable solution would be to
42*9880d681SAndroid Build Coastguard Workerdisable trace generation on functions that have variable-sized
43*9880d681SAndroid Build Coastguard Workeralloca()s. Variable-sized allocas in the trace would also probably
44*9880d681SAndroid Build Coastguard Workerscrew things up.
45*9880d681SAndroid Build Coastguard Worker
46*9880d681SAndroid Build Coastguard WorkerBecause of the FP and alloca limitations, the BinInterface is
47*9880d681SAndroid Build Coastguard Workercompletely disabled right now.
48*9880d681SAndroid Build Coastguard Worker
49*9880d681SAndroid Build Coastguard Worker
50*9880d681SAndroid Build Coastguard WorkerDemo
51*9880d681SAndroid Build Coastguard Worker----
52*9880d681SAndroid Build Coastguard Worker
53*9880d681SAndroid Build Coastguard WorkerThis is a demo of the Ball & Larus version that does NOT use 2-level
54*9880d681SAndroid Build Coastguard Workerprofiling.
55*9880d681SAndroid Build Coastguard Worker
56*9880d681SAndroid Build Coastguard Worker1. Compile program with llvm-gcc.
57*9880d681SAndroid Build Coastguard Worker2. Run opt -lowerswitch -paths -emitfuncs on the bytecode.
58*9880d681SAndroid Build Coastguard Worker   -lowerswitch change switch statements to branches
59*9880d681SAndroid Build Coastguard Worker   -paths       Ball & Larus path-profiling algorithm
60*9880d681SAndroid Build Coastguard Worker   -emitfuncs   emit the table of functions
61*9880d681SAndroid Build Coastguard Worker3. Run llc to generate SPARC assembly code for the result of step 2.
62*9880d681SAndroid Build Coastguard Worker4. Use g++ to link the (instrumented) assembly code.
63*9880d681SAndroid Build Coastguard Worker
64*9880d681SAndroid Build Coastguard WorkerWe use a script to do all this:
65*9880d681SAndroid Build Coastguard Worker------------------------------------------------------------------------------
66*9880d681SAndroid Build Coastguard Worker#!/bin/sh
67*9880d681SAndroid Build Coastguard Workerllvm-gcc $1.c -o $1
68*9880d681SAndroid Build Coastguard Workeropt -lowerswitch -paths -emitfuncs $1.bc > $1.run.bc
69*9880d681SAndroid Build Coastguard Workerllc -f $1.run.bc
70*9880d681SAndroid Build Coastguard WorkerLIBS=$HOME/llvm_sparc/lib/Debug
71*9880d681SAndroid Build Coastguard WorkerGXX=/usr/dcs/software/evaluation/bin/g++
72*9880d681SAndroid Build Coastguard Worker$GXX -g -L $LIBS $1.run.s -o $1.run.llc \
73*9880d681SAndroid Build Coastguard Worker$LIBS/tracecache.o \
74*9880d681SAndroid Build Coastguard Worker$LIBS/mapinfo.o \
75*9880d681SAndroid Build Coastguard Worker$LIBS/trigger.o \
76*9880d681SAndroid Build Coastguard Worker$LIBS/profpaths.o \
77*9880d681SAndroid Build Coastguard Worker$LIBS/bininterface.o \
78*9880d681SAndroid Build Coastguard Worker$LIBS/support.o \
79*9880d681SAndroid Build Coastguard Worker$LIBS/vmcore.o \
80*9880d681SAndroid Build Coastguard Worker$LIBS/transformutils.o \
81*9880d681SAndroid Build Coastguard Worker$LIBS/bcreader.o \
82*9880d681SAndroid Build Coastguard Worker-lscalaropts -lscalaropts -lanalysis \
83*9880d681SAndroid Build Coastguard Worker-lmalloc -lcpc -lm -ldl
84*9880d681SAndroid Build Coastguard Worker------------------------------------------------------------------------------
85*9880d681SAndroid Build Coastguard Worker
86*9880d681SAndroid Build Coastguard Worker5. Run the resulting binary.  You will see output from BinInterface
87*9880d681SAndroid Build Coastguard Worker(described below) intermixed with the output from the program.
88*9880d681SAndroid Build Coastguard Worker
89*9880d681SAndroid Build Coastguard Worker
90*9880d681SAndroid Build Coastguard WorkerOutput from BinInterface
91*9880d681SAndroid Build Coastguard Worker------------------------
92*9880d681SAndroid Build Coastguard Worker
93*9880d681SAndroid Build Coastguard WorkerBinInterface's debugging code prints out the following stuff in order:
94*9880d681SAndroid Build Coastguard Worker
95*9880d681SAndroid Build Coastguard Worker1. Initial code provided to BinInterface with original register
96*9880d681SAndroid Build Coastguard Workerallocation.
97*9880d681SAndroid Build Coastguard Worker
98*9880d681SAndroid Build Coastguard Worker2. Section 0 is the trace prolog, consisting mainly of live-ins and
99*9880d681SAndroid Build Coastguard Workerregister saves which will be restored in epilogs.
100*9880d681SAndroid Build Coastguard Worker
101*9880d681SAndroid Build Coastguard Worker3. Section 1 is the trace itself, in SSA form used by BinInterface,
102*9880d681SAndroid Build Coastguard Workeralong with the PHIs that are inserted.
103*9880d681SAndroid Build Coastguard WorkerPHIs are followed by the copies that implement them.
104*9880d681SAndroid Build Coastguard WorkerEach branch (i.e., out of the trace) is annotated with the
105*9880d681SAndroid Build Coastguard Workersection number that represents the epilog it branches to.
106*9880d681SAndroid Build Coastguard Worker
107*9880d681SAndroid Build Coastguard Worker4. All the other sections starting with Section 2 are trace epilogs.
108*9880d681SAndroid Build Coastguard WorkerEvery branch from the trace has to go to some epilog.
109*9880d681SAndroid Build Coastguard Worker
110*9880d681SAndroid Build Coastguard Worker5. After the last section is the register allocation output.
111