JIT: cmp + jump + jump

[EgorBo]

From: #101153

[MethodImpl(MethodImplOptions.NoInlining)]
static void Foo<T>() => Bar<T>();

[MethodImpl(MethodImplOptions.NoInlining)]
static void Bar<T>() { }

Codegen for Foo<_Canon> in Tier1:

; Assembly listing for method Prog:Foo[System.__Canon]() (FullOpts)
; FullOpts code
       sub      rsp, 40
       mov      qword ptr [rsp+0x20], rcx
       mov      rdx, qword ptr [rcx+0x38]
       mov      rdx, qword ptr [rdx+0x10]
       test     rdx, rdx
       je       SHORT G_M2381_IG04
       jmp      SHORT G_M2381_IG05
G_M2381_IG04:
       mov      rdx, 0x7FFE1F42D630 
       call     CORINFO_HELP_RUNTIMEHANDLE_METHOD
       mov      rdx, rax
G_M2381_IG05:
       mov      rcx, rdx
       call     [Prog:Bar[System.__Canon]()]
       nop      
       add      rsp, 40
       ret      

this block:

       test     rdx, rdx
       je       SHORT G_M2381_IG04
       jmp      SHORT G_M2381_IG05
G_M2381_IG04:

seems like it's better to be re-ordered to:

       test     rdx, rdx
       jne       SHORT G_M2381_IG05
G_M2381_IG04:

@amanasifkhalid something you might find interesting to take a look since it's block re-ordering. cc @dotnet/jit-contrib

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jkotas]

The existing code works well for static branch prediction: forward branches are statically predicted to fall-through.

The best block re-ordering would be:

      sub      rsp, 40
       mov      qword ptr [rsp+0x20], rcx
       mov      rdx, qword ptr [rcx+0x38]
       mov      rdx, qword ptr [rdx+0x10]
       test     rdx, rdx
       je       SHORT G_M2381_IG04
G_M2381_IG05:
       mov      rcx, rdx
       call     [Prog:Bar[System.__Canon]()]
       nop      
       add      rsp, 40
       ret      

G_M2381_IG04:
       mov      rdx, 0x7FFE1F42D630 
       call     CORINFO_HELP_RUNTIMEHANDLE_METHOD
       mov      rdx, rax
       jmp      SHORT G_M2381_IG05

[EgorBo]

The best block re-ordering would be:

This can be easily done, I just remember we discussed that the helper call path is always invoked at least once so marking it as cold might slightly regress startup

[jkotas]

This is the previous discussion for reference: #83911 (comment)

[EgorBo]

Current codegen:

; Assembly listing for method Class1:Foo[System.__Canon]() (FullOpts)
; Emitting BLENDED_CODE for X64 with AVX512 - Windows
; FullOpts code
; optimized code
; rsp based frame
; partially interruptible
; No PGO data
; Final local variable assignments
;
;  V00 TypeCtx      [V00,T00] (  5,  4.20)    long  ->  rcx         single-def
;  V01 OutArgs      [V01    ] (  1,  1   )  struct (32) [rsp+0x00]  do-not-enreg[XS] addr-exposed "OutgoingArgSpace"
;* V02 tmp1         [V02    ] (  0,  0   )    long  ->  zero-ref    "spilling helperCall"
;  V03 rat0         [V03,T02] (  3,  4   )    long  ->  rdx         "runtime lookup"
;  V04 rat1         [V04,T01] (  3,  5.60)    long  ->  rdx         "fgMakeTemp is creating a new local variable"
;
; Lcl frame size = 40

G_M6360_IG01:  ;; offset=0x0000
       sub      rsp, 40
       mov      qword ptr [rsp+0x20], rcx
						;; size=9 bbWeight=1 PerfScore 1.25
G_M6360_IG02:  ;; offset=0x0009
       mov      rdx, qword ptr [rcx+0x40]
       mov      rdx, qword ptr [rdx+0x10]
       test     rdx, rdx
       je       SHORT G_M6360_IG05
						;; size=13 bbWeight=1 PerfScore 5.25
G_M6360_IG03:  ;; offset=0x0016
       mov      rcx, rdx
       call     [Class1:Bar[System.__Canon]()]
       nop      
						;; size=10 bbWeight=1 PerfScore 3.50
G_M6360_IG04:  ;; offset=0x0020
       add      rsp, 40
       ret      
						;; size=5 bbWeight=1 PerfScore 1.25
G_M6360_IG05:  ;; offset=0x0025
       mov      rdx, 0x7FFF023B7BF0      ; global ptr
       call     CORINFO_HELP_RUNTIMEHANDLE_METHOD
       mov      rdx, rax
       jmp      SHORT G_M6360_IG03
						;; size=20 bbWeight=0.20 PerfScore 0.70

; Total bytes of code 57