search

matsc-at-sics-se / unison

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

rematerialization needs extension for a common idiom #39

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

matsc-at-sics-se commented 6 years ago

A common idiom is code like

    o3: [t9] <- MOV32ri64 [512]
    o4: [t10] <- (define) []
    o5: [t11] <- (combine) [t9,t10]

where t11 is a 64-bit quantity for later use. Unfortunately, t11 is not rematerializable. We should have a rematerializable pseudo that captures {o3,o4,o5}.

A function that suffers from this is atom_buffer_init. Due to this phenomenon, 512 is made and spilled in one block, and unspilled in another block.

uni import -f atom_buffer_init atom_buffer_init.mir -o atom_buffer_init.uni --target=X86 --explicitcallreg --maxblocksize=25 --goal=speed --copyremat --lint
uni linearize atom_buffer_init.uni -o atom_buffer_init.lssa.uni --target=X86 --lint
uni extend atom_buffer_init.lssa.uni -o atom_buffer_init.ext.uni --target=X86 --lint
uni augment atom_buffer_init.ext.uni -o atom_buffer_init.alt.uni --target=X86 --copyremat --lint

etc. atom_buffer_init.mir.zip

matsc-at-sics-se commented 6 years ago

Fixed by commit d597c2e0a24e3ff1bfb585d9f0d899559fc6aaf9. _cpp_init_internal_pragmas was another case for this.