Skip to content
  • Lang Hames's avatar
    1662b832
    Rewrite the PBQP graph data structure. · 1662b832
    Lang Hames authored
    The new graph structure replaces the node and edge linked lists with vectors.
    Free lists (well, free vectors) are used for fast insertion/deletion.
    
    The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
    the PBQP solver destructively consumes input graphs while computing a solution,
    forcing the graph to be fully reconstructed for each round of PBQP. This
    imposes a high cost on large functions, which often require several rounds of
    solving/spilling to find a final register allocation. If we can cheaply clone
    the PBQP graph and incrementally update it between rounds then hopefully we can
    reduce this cost. Further, once we begin pooling matrix/vector values (future
    work), we can cache some PBQP solver metadata and share it between cloned
    graphs, allowing the PBQP solver to re-use some of the computation done in
    earlier rounds.
    
    For now this is just a data structure update. The allocator and solver still
    use the graph the same way as before, fully reconstructing it between each
    round. I expect no material change from this update, although it may change
    the iteration order of the nodes, causing ties in the solver to break in
    different directions, and this could perturb the generated allocations
    (hopefully in a completely benign way).
    
    Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
    to work on this, and for a lot of discussion and many useful PBQP test cases.
    
    llvm-svn: 194300
    1662b832
    Rewrite the PBQP graph data structure.
    Lang Hames authored
    The new graph structure replaces the node and edge linked lists with vectors.
    Free lists (well, free vectors) are used for fast insertion/deletion.
    
    The ultimate aim is to make PBQP graphs cheap to clone. The motivation is that
    the PBQP solver destructively consumes input graphs while computing a solution,
    forcing the graph to be fully reconstructed for each round of PBQP. This
    imposes a high cost on large functions, which often require several rounds of
    solving/spilling to find a final register allocation. If we can cheaply clone
    the PBQP graph and incrementally update it between rounds then hopefully we can
    reduce this cost. Further, once we begin pooling matrix/vector values (future
    work), we can cache some PBQP solver metadata and share it between cloned
    graphs, allowing the PBQP solver to re-use some of the computation done in
    earlier rounds.
    
    For now this is just a data structure update. The allocator and solver still
    use the graph the same way as before, fully reconstructing it between each
    round. I expect no material change from this update, although it may change
    the iteration order of the nodes, causing ties in the solver to break in
    different directions, and this could perturb the generated allocations
    (hopefully in a completely benign way).
    
    Thanks very much to Arnaud Allard de Grandmaison for encouraging me to get back
    to work on this, and for a lot of discussion and many useful PBQP test cases.
    
    llvm-svn: 194300
Loading