Solving the Simple Oset Assignment Problem as a Traveling Salesman

Transcription

1 Solving the Simple Oset Assignment Problem as a Traveling Salesman Michael Jünger and Sven Mallach 1 Institut für Informatik Lehrstuhl Prof. Dr. M. Jünger Universität zu Köln 19th June, 2013 M-SCOPES 2013, St. Goar 1 mallach@informatik.uni-koeln.de

2 Motivation: Address Code for ASIPs To save silicon area, ASIPs frequently do not support `base-plus-oset' addressing modes. 0FFFA AR FFF9 0FFFA 0FFFB 0FFFC 0FFFD

3 Motivation: Address Code for ASIPs To save silicon area, ASIPs frequently do not support `base-plus-oset' addressing modes. 0FFFC AR FFF9 0FFFA 0FFFB 0FFFC 0FFFD Instead: Indirect memory addressing only (oset 0). But often, modications to ARs can be encoded into other instructions if distance to new address is `small', e.g., 1 word. autoin-/decrement denoted, e.g., ADD *(AR0)+ / ADD *(AR0)-

4 Address Code - Example Suppose we are given a stack layout of local program variables of a basic block, e.g., {a, b,..., g} and a sequence of scheduled three-address-code instructions. a b g c f d e AR a b g c f d e c = a + b f = g - c... access sequence a b c g c f...

5 Address Code - Example 3-address code: c = a + b f = g - c access sequence: a b c g c f LDAR AR, &a // AR = a LOAD *(AR)+ // ACC = a,ar = b ADD *(AR) // ACC += b ADAR AR,2 // AR = c STOR *(AR)- // c = ACC,AR = g Stack layout: a b g c f d e

6 Address Code - Example 3-address code: c = a + b f = g - c access sequence: a b c g c f LDAR AR, &a // AR = a LOAD *(AR)+ // ACC = a,ar = b ADD *(AR) // ACC += b ADAR AR,2 // AR = c STOR *(AR)- // c = ACC,AR = g Stack layout: a b g c f d e

7 Address Code - Example 3-address code: c = a + b f = g - c access sequence: a b c g c f LDAR AR, &a // AR = a LOAD *(AR)+ // ACC = a,ar = b ADD *(AR) // ACC += b ADAR AR,2 // AR = c STOR *(AR)- // c = ACC,AR = g Stack layout: a b g c f d e

8 Address Code - Example 3-address code: c = a + b f = g - c access sequence: a b c g c f LDAR AR, &a // AR = a LOAD *(AR)+ // ACC = a,ar = b ADD *(AR) // ACC += b ADAR AR,2 // AR = c STOR *(AR)- // c = ACC,AR = g Stack layout: a b g c f d e

9 Address Code / SOA Non-neighboring accesses (`jumps') need additional address arithmetic instructions. ranges > 1 / Modify Registers: changing the `jump distance' also needs additional instructions. Since the stack layout (`osets') of local variables can be freely chosen and each autoin-/decrement saves code size and execution time it is natural to optimize the stack layout to maximize their use. Simple Oset Assignment (SOA) Problem

10 Access graphs First intuition: Place variable pairs with many access transitions as neighbors of each other.

11 Access graphs First intuition: Place variable pairs with many access transitions as neighbors of each other. Usual approach: Create an access graph G = (V, E) from an access sequence S as follows: S = a b c g c f c e c c f d

12 Access graphs First intuition: Place variable pairs with many access transitions as neighbors of each other. Usual approach: Create an access graph G = (V, E) from an access sequence S as follows: Let V represent the set of program variables, S = a b c g c f c e c c f d a b g c e f d

13 Access graphs First intuition: Place variable pairs with many access transitions as neighbors of each other. Usual approach: Create an access graph G = (V, E) from an access sequence S as follows: Let V represent the set of program variables, Add edge e = (u, v) E with weight w e = k if u and v are neighbors in S for k times. S = a b c g c f c e c c f d a c 1 1 b g 2 2 e 3 f 1 d

14 Access graphs a 1 1 c b g 2 2 e 3 f 1 d Theorem (Bartley [1992]): The optimum oset assignment corresponds to amaximum-weight Hamiltonian Path (MWHP) in the completed access graph.

15 Access graphs a 1 1 c b g 2 2 e 3 f 1 d 0 Theorem (Bartley [1992]): The optimum oset assignment corresponds to a Maximum-Weight Hamiltonian Path (MWHP) in the completed access graph.

16 Access graphs a 1 1 c b g 2 2 e 3 f 1 d Theorem (Liao [1996]): The optimum oset assignment corresponds to a Maximum-Weight Path Cover (MWPC) in the (original) access graph. The paths can be concatenated to a stack layout in arbitrary order.

17 Solving SOA In 2003, Leupers compared a set of existing SOA/MWPC heuristics with a benchmark set called OsetStone. However, due to a lack of optimum solutions, the quality of the heuristics could only be veried for some small instances. Our Contribution: An exact ILP approach to solve SOA as a Maximum-Weight Hamiltonian Cycle problem - delivering optimum solutions for all instances of OsetStone. Evaluation of the quality of the existing heuristics. A new heuristic based on a Lin-Kerninghan heuristic for TSPs. First results on OsetStone for a heuristic presented at SCOPES 2008.

18 SOA-MWHC SOA-MWHC: Branch-and-Cut algorithm for the Maximum-Weight Hamiltonian Cycle problem, working on a complete graph G = (V, E ) dened from an access graph G = (V, E) as follows: V = V {z} E = E E 0 E z where E 0 is the set of zero-weight edges for any edge e, e E E z = { {v, z} v V } (each having zero-weight, too) z a 1 1 c b f 1 g e d 0

19 SOA-MWHC SOA-MWHC: Branch-and-Cut algorithm for the Maximum-Weight Hamiltonian Cycle problem, working on a complete graph G = (V, E ) dened from an access graph G = (V, E) as follows: V = V {z} E = E E 0 E z where E 0 is the set of zero-weight edges for any edge e, e E E z = { {v, z} v V } (each having zero-weight, too) u 0 z 0 v u v

20 SOA-MWHC Transformation to a Hamiltonian Cycle problem yields a well-studied problem: With minimization objective this is the Traveling Salesman Problem (TSP). Knowledge about the polytope of Hamiltonian Cycles (tours) to solve the problem to optimality using integer programming. Possibility to directly use TSP-heuristics for SOA, such as the Lin-Kernighan algorithm.

21 SOA-MWHC Let G = (V, E) be a complete graph and denote with w e the weight of an edge e E. Further, we have decision variables x e = { 1, e cycle/tour T 0, otherwise Then, an ILP formulation for the MWHC problem is: max w e x e e E x(δ(v)) = 2 v V x(e(w )) W 1 W V x e {0, 1} e E (with δ(v) = {e = {v, w} E} and x(e(w )) = { x e e = {u, v} E and u, v W }).

22 SOA-MWHC max MWHC - IP Formulation w e x e e E x(δ(v)) = 2 v V x(e(w )) W 1 W V x e {0, 1} e E Branch & Cut LP-Solver Cutting Planes Completed Access Graph with Dummy Vertex a c z b g 2 f e 1 d 0 Optimum Hamiltonian Path a 1 b g 2 c e 3 f 1 d Separation Algorithms Branch & Bound Primal Heuristics stack-layout a b g c f...

23 Experiments - OsetStone OsetStone comprises realistic instances (access sequences) extracted from ANSI C programs. Several benchmarks consisting of multiple access sequences with up to 1336 program variables. Our Experiments: Only sequences with at least 10 variables. Summarized Oset Assignment Cost: Sum of explicit address arithmetic instructions needed for all sequences of a benchmark. OffsetStone Benchmarks adpcm access sequences fft access sequences gzip access sequences mp3 access sequences... access sequences

24 Experiments - Algorithm Overview SOA-Liao: A greedy heuristic presented by Liao [1996]. SOA-TB: Liao's heuristic extended by a tie-break function of Leupers and Marwedel [1997]. SOA-INC: An improvement heuristic by Atri et al. [2001] using SOA-Liao for an initial solution. SOA-INC-TB: As SOA-INC but using SOA-TB for an initial solution. SOA-GA: A genetic algorithm of Leupers and David [1998]. SOA-TB2 - like SOA-TB but with a dierent tie-break function of Ali et al. [2008] (SCOPES). SOA-MWHC: Our exact solver. SOA-TBLK: Our combination of SOA-TB with a Lin-Kernighan heuristic for TSPs.

25 Results - Quality Summarized Offset Assignment Cost (% to Optimum) fft Liao TB TB2 INC INC-TB TBLK GA MWHC Quality of SOA heuristics on OffsetStone viterbi anagram adpcm 8051 gsm cavity triangle mpeg2 mp3 klt dspstone h263 motion jpeg hmm flex sparse bdd anthr gzip gif2asc random f2c cc65 cpp codecs bison lpsolve dct-unr. fuzzy eqntott Benchmark

26 Results - Runtime INC-TB TBLK GA MWHC Runtime of selected SOA algorithms on OffsetStone w/o random instances Runtime (in s) 100 viterbi triangle sparse mpeg2 mp3 motion lpsolve klt jpeg hmm h263 gzip gsm gif2asc fuzzy flex fft f2c eqntott dspstone dct-unr. cpp codecs cc65 cavity bison bdd anthr anagram adpcm Benchmark

27 Summary of Main Results and Conclusions SOA-MWHC solves most of the instances to optimality within a few ms (on a Core i7 3.2 GHz, 6 GB RAM). All heuristics within 8.5% of optimum summarized oset assignment cost. On single instances 10% relative loss possible. Best heuristic appears to be SOA-INC-TB. Sometimes it is outperformed by SOA-TBLK which is much slower though. SOA-TBLK is faster than SOA-GA while delivering competitive solutions. SOA-TB2 was mostly inferior to SOA-TB.

28 Questions and Outlook Major question: Is OsetStone representative for the complexity of real-world instances? If so, optimal solutions for SOA could be achievable in compilers for a large set of them. However, then also the loss of the heuristics appears to be acceptable. If not, it would be nice to deliver a new benchmark set of instances. Going further: Try to exploit the structure of access graphs. Going further: Consider multiple ARs, ranges > 1 and modify registers.