#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 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 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 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 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 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d 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 0x0000000002cf5967 <+103>: jmp 0x2cf5953 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 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 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 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 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 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 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d 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 0x0000000002cf5967 <+103>: jmp 0x2cf5953 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 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