-dynamic-too implementation is unnecessarily inefficient

-dynamic-too runs the compilation starting from Core-to-STG twice. So that's two Core-to-STG, STG-to-Cmm, Cmm-to-native-code for one module. As far as I can see the code generator does not care about -dynamic-too at all -- so in these two compilation we generate identical code. I think the only difference is in linking, so unless I'm missing something implementation of -dynamic-too could be made much more efficient by only linking twice.

added needs triage label

Hi @osa1. FWIW the generated assembly is slightly different as well as relocations.

For instance, this module

module Foo (foo) where
foo x = x * 3

$ ghc -c -dynamic-too Foo.hs

Excerpt from the assembly diff:

$ diff -u <(objdump -D Foo.o) <(objdump -D Foo.dyn_o)
-Foo.o:
+Foo.dyn_o:
...
-	leaq	_stg_ap_pp_info(%rip), %rax
+	movq	_stg_ap_pp_info(%rip), %rax
...
-	jmp	_base_GHCziNum_zt_info
+	jmpq	*_base_GHCziNum_zt_info(%rip)
...

Same for relocations:

$ diff -u <(objdump -r Foo.o) <(objdump -r Foo.dyn_o)
- X86_64_RELOC_BRANCH _base_GHCziNum_zt_info
- X86_64_RELOC_SIGNED _stg_ap_pp_info
...
+ X86_64_RELOC_GOT _base_GHCziNum_zt_info@GOTPCREL
+ X86_64_RELOC_GOT_LOAD _stg_ap_pp_info@GOTPCREL

Hmm, good catch, thanks @artempyanykh . I checked GHC-generated assembly and this is the diff:

--- Foo.dump-asm	2019-11-26 09:50:51.942355328 +0300
+++ Foo.dump-asm-2	2019-11-26 09:50:52.482359960 +0300
@@ -6,32 +6,35 @@
 	.quad	1
 	.long	16
 	.long	0
-sat_s1bI_info:
-_c1bS:
+sat_s1ch_info:
+_c1cr:
 	leaq -32(%rbp),%rax
 	cmpq %r15,%rax
-	jb _c1bT
-_c1bU:
+	jb _c1cs
+_c1ct:
 	addq $16,%r12
 	cmpq 856(%r13),%r12
-	ja _c1bW
-_c1bV:
-	movq $stg_upd_frame_info,-16(%rbp)
+	ja _c1cv
+_c1cu:
+	movq stg_upd_frame_info@gotpcrel(%rip),%rax
+	movq %rax,-16(%rbp)
 	movq %rbx,-8(%rbp)
 	movq 16(%rbx),%rax
-	movq $GHC.Integer.Type.S#_con_info,-8(%r12)
+	movq GHC.Integer.Type.S#_con_info@gotpcrel(%rip),%rbx
+	movq %rbx,-8(%r12)
 	movq $3,(%r12)
 	leaq -7(%r12),%rbx
 	movq %rax,%r14
-	movq $stg_ap_p_info,-32(%rbp)
+	movq stg_ap_p_info@gotpcrel(%rip),%rax
+	movq %rax,-32(%rbp)
 	movq %rbx,-24(%rbp)
 	addq $-32,%rbp
-	jmp GHC.Num.fromInteger_info
-_c1bW:
+	jmp *GHC.Num.fromInteger_info@gotpcrel(%rip)
+_c1cv:
 	movq $16,904(%r13)
-_c1bT:
+_c1cs:
 	jmp *-16(%r13)
-	.size sat_s1bI_info, .-sat_s1bI_info
+	.size sat_s1ch_info, .-sat_s1ch_info
 
 
 ==================== Asm code ====================
@@ -46,27 +49,29 @@
 .globl Foo.foo_info
 .type Foo.foo_info, @object
 Foo.foo_info:
-_c1bX:
+_c1cw:
 	leaq -24(%rbp),%rax
 	cmpq %r15,%rax
-	jb _c1bY
-_c1bZ:
+	jb _c1cx
+_c1cy:
 	addq $24,%r12
 	cmpq 856(%r13),%r12
-	ja _c1c1
-_c1c0:
-	movq $sat_s1bI_info,-16(%r12)
+	ja _c1cA
+_c1cz:
+	leaq sat_s1ch_info(%rip),%rax
+	movq %rax,-16(%r12)
 	movq %r14,(%r12)
 	leaq -16(%r12),%rax
-	movq $stg_ap_pp_info,-24(%rbp)
+	movq stg_ap_pp_info@gotpcrel(%rip),%rbx
+	movq %rbx,-24(%rbp)
 	movq %rsi,-16(%rbp)
 	movq %rax,-8(%rbp)
 	addq $-24,%rbp
-	jmp GHC.Num.*_info
-_c1c1:
+	jmp *GHC.Num.*_info@gotpcrel(%rip)
+_c1cA:
 	movq $24,904(%r13)
-_c1bY:
-	movl $Foo.foo_closure,%ebx
+_c1cx:
+	leaq Foo.foo_closure(%rip),%rbx
 	jmp *-8(%r13)
 	.size Foo.foo_info, .-Foo.foo_info
 
@@ -133,4 +138,3 @@
 	.quad	$trModule4_r1bs_closure+1
 	.quad	3
 
-

So it seems like we do generate different code.

However I still think the Cmms we generate are identical. If that's really the case then the implementation can still be improved by only running X86 generation and linking twice.

Looking at native code generator (compiler/nativeGen) I don't see any code that checks WayDyn. I wonder where we check this and generate different code based on that?

Hmm, actually there are differences in -ddump-opt-cmm outputs, so final Cmms are different too.

It's probably this function

cmmMakeDynamicReference dflags referenceKind lbl
  | Just _ <- dynamicLinkerLabelInfo lbl
  = return $ CmmLit $ CmmLabel lbl   -- already processed it, pass through

  | otherwise
  = do this_mod <- getThisModule
       case howToAccessLabel
                dflags
                (platformArch $ targetPlatform dflags)
                (platformOS   $ targetPlatform dflags)
                this_mod
                referenceKind lbl of

        AccessViaStub -> do
              let stub = mkDynamicLinkerLabel CodeStub lbl
              addImport stub
              return $ CmmLit $ CmmLabel stub

        AccessViaSymbolPtr -> do
              let symbolPtr = mkDynamicLinkerLabel SymbolPtr lbl
              addImport symbolPtr
              return $ CmmLoad (cmmMakePicReference dflags symbolPtr) (bWord dflags)

        AccessDirectly -> case referenceKind of
                -- for data, we might have to make some calculations:
              DataReference -> return $ cmmMakePicReference dflags lbl
                -- all currently supported processors support
                -- PC-relative branch and call instructions,
                -- so just jump there if it's a call or a jump
              _ -> return $ CmmLit $ CmmLabel lbl

Yes, seems so. With dynamic linking we need an indirection against GOT to access symbols, thus mov instead of lea and indirect jumps instead of direct ones in the generated code.

We don't check WayDyn anywhere in the backend, but we check Opt_ExternalDynamicRefs which is enabled by WayDyn.

I'm not 100% sure, but I think StgToCmm can be run only once, the rest needs to be run twice.

I suspect you are right, C-- should abstract away the differences in dynamic. Consequently it should be possible to run StgToCmm only once.

added Pnormal Ttask labels and removed needs triage label

added dynamic-too label

assigned to @dfordivam

There is a plan to tackle this in #14095

marked this issue as related to #14095

mentioned in issue #14095

added to epic &2