Opportunity to do better in register allocations
This github repo demonstrates that introduction of one "if" condition which is never taken, degrades the performance of the fast path loop in this particular use case by around 70%, from 2.6ms to 4.4 ms.
On investigation I found two main issues. See #12231(ticket) regarding rdeundant allocations. This one is about the other issue regarding register allocations.
See this assembly diff of instructions executed in both cases. The repo has both versions to play with and simpl/stg/cmm/asm are checked in. The first file in the diff is with the if condition and the second one without. Look for git tags ghc-trac-12232-better and ghc-trac-12232-worse for the two versions.
To summarize, the introduction of "if" condition adds the following register manipulations before and after the main logic:
# reassignments
# rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx
=> 0x408d7e: mov %rbx,0x90(%rsp)
=> 0x408d86: mov %rcx,%rbx
=> 0x408d89: mov %rdx,%rcx
=> 0x408d8c: mov %rsi,%rdx
=> 0x408d8f: mov %rdi,%rsi
=> 0x408d92: mov %r8,%rdi
=> 0x408d95: mov %r9,%r8
=> 0x408d98: mov %r10,%r9
=> 0x408d9b: mov 0x90(%rsp),%r10
.
.
.
loop logic here which uses only %rax, %r10 and %r9 .
.
.
.
# _n4s8:
# shuffle back to original assignments
=> 0x4090dc: mov %r14,%r11
=> 0x4090df: mov %r9,%r10
=> 0x4090e2: mov %r8,%r9
=> 0x4090e5: mov %rdi,%r8
=> 0x4090e8: mov %rsi,%rdi
=> 0x4090eb: mov %rdx,%rsi
=> 0x4090ee: mov %rcx,%rdx
=> 0x4090f1: mov %rbx,%rcx
=> 0x4090f4: mov %rax,%rbx
=> 0x4090f7: mov 0x88(%rsp),%rax
=> 0x4090ff: jmpq 0x408d2a
The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. My suspicion is that this allocation is being done en bloc keeping several paths in mind, just like the heap allocations I reported in the other issue.
Some questions to be answered:
- Can we make this smarter?
- Will
-fregs-graph
do a better job and if not what improvements can be done to graph coloring allocator to do a good job here? I have try that option yet.
LLVM assembly trace is also available in the repo.
References
- [1] mail thread: https://mail.haskell.org/pipermail/ghc-devs/2016-June/012243.html
- [2] github code repo: https://github.com/harendra-kumar/unicode-transforms/tree/ghc-trac-12232-better