search

matsc-at-sics-se / unison

Unison's source code
http://unison-code.github.io/
Other
5 stars 0 forks source link

'uni import' --maxblocksize: block split after epilogue causes bug #31

Closed matsc-at-sics-se closed 6 years ago

matsc-at-sics-se commented 6 years ago

Context: the prologue/epilogue logic includes the following steps: uni import: insert prolgue/epilogue uni extend: insert optional spill/unspill uni augment: move some spill to after prologue; some unspill to before epilogue

This has to do with two types of spill/unspill: callee-saved: done with push before prologue and pop after prologue (no problem) others: done with store after prologue and load before epilogue (problem)

Only the latter is subject to moving. This breaks down if the block is split after the epilogue, because then the unspills to move and the epilogue are in different blocks.

Example from running uni import:

Before splitBlocks:

    o203: [] <- VMOVAPSYmr [t17,1,t180,32,_,t186] (mem: 0)
    o204: [] <- VMOVAPSYmr [t17,1,t180,0,_,t185] (mem: 0)
    o375: [] <- MOV_TO_SP [t192]
    o392: [] <- VZEROUPPER []
    o205: [] <- RETQ [42]
    o364: [] <- (out) [t331:rbx,t332:rbp,t333:r12,t334:r13,t335:r14,t336:r15,t126:rsp,t338:rip]
b3 (freq: 255):
    o370: [] <- (in) []
    o207: [t13] <- (phi) [t52,b1,t16,b3]
    o208: [t14] <- (phi) [t52,b1,t15,b3]

After splitBlocks:

    o201: [t185] <- VMOVAPSYrm [%stack.22,1,_,0,_] (mem: 0)
    o202: [t186] <- VMOVAPSYrm [%stack.22,1,_,32,_] (mem: 0)
    o203: [] <- VMOVAPSYmr [t17,1,t180,32,_,t186] (mem: 0)
    o204: [] <- VMOVAPSYmr [t17,1,t180,0,_,t185] (mem: 0)
    o375: [] <- MOV_TO_SP [t192]
    o432: [] <- (out) []
b9 (exit, return, freq: 16, split):
    o430: [] <- (in) []
    o392: [] <- VZEROUPPER []
    o205: [] <- RETQ [42]
    o364: [] <- (out) [t331:rbx,t332:rbp,t333:r12,t334:r13,t335:r14,t336:r15,t126:rsp,t338:rip]
b3 (freq: 255):
    o370: [] <- (in) []
    o207: [t13] <- (phi) [t52,b1,t16,b12]
    o208: [t14] <- (phi) [t52,b1,t15,b12]

So the newly spawned b9 is an exit block without an epilogue, which breaks the logic.

Work-around for now: not using --maxblocksize.

robcasloz commented 6 years ago

A solution would be to create a new operation attribute that tells splitBlocks to avoid splitting between the operation and the end of the block.