[GHC] #14753: Assembly for stg_enter_info starts with a dead 'mov'
#14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d <stg_enter_info+61> 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 <stg_enter_info+71> 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d <stg_enter_info+45> 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 <stg_enter_info+51> 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 <stg_enter_info+8> 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 <stg_enter_info+105> 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d <stg_enter_info+93> 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5967 <+103>: jmp 0x2cf5953 <stg_enter_info+83> 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by alpmestan: Old description:
In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb:
{{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d <stg_enter_info+61> 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 <stg_enter_info+71> 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d <stg_enter_info+45> 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 <stg_enter_info+51> 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 <stg_enter_info+8> 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 <stg_enter_info+105> 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d <stg_enter_info+93> 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5967 <+103>: jmp 0x2cf5953 <stg_enter_info+83> 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}}
Notice the first two instructions:
{{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}}
We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful.
I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`.
(Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.)
New description: In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d <stg_enter_info+61> 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 <stg_enter_info+71> 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d <stg_enter_info+45> 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 <stg_enter_info+51> 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 <stg_enter_info+8> 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 <stg_enter_info+105> 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d <stg_enter_info+93> 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 <stg_enter_info+33> 0x0000000002cf5967 <+103>: jmp 0x2cf5953 <stg_enter_info+83> 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 <stg_enter_info+33> 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 ENTER], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 LOAD_INFO], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14753#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC