@EgorBo PTAL
cc @dotnet/jit-contrib

Note we are trustingGTF_EXCEPT fairly early... I think this is ok (it is glob ref that is iffy). Should be small number of diffs, but potential for more down the road with some work I have in flight.

If no tree in the try region of a try/finally can throw, we can remove the try and inline the finally.

Just wondering - We used to have some special meaning for code in finally with respect to ThreadAbort. Is that no longer a thing or still somehow maintained when finally is inlined?

If no tree in the try region of a try/finally can throw, we can remove the try and inline the finally.

Just wondering - We used to have some special meaning for code in finally with respect to ThreadAbort. Is that no longer a thing or still somehow maintained when finally is inlined?

AFAIR all the handling for that was removed.

If no tree in the try region of a try/finally can throw, we can remove the try and inline the finally.

Just wondering - We used to have some special meaning for code in finally with respect to ThreadAbort. Is that no longer a thing or still somehow maintained when finally is inlined?

AFAIR all the handling for that was removed.

That is only an issue for .NET Framework. Removal of empty-try / finally has been in .NET Core since 2.x, this just extends it a bit further to some trys that are not empty.

I remember long time ago we could do similar optimizations in Roslyn, in theory, but in practice we could not.
And I guess it is still not feasible on Roslyn side since targeting .net FX is still a real scenario.

On x86 we have callfinallys within the try. In this case inside the try/finally there is a try/catch that returns from the catch, so must invoke the outer finally, thus there is a callfinally pair in the catch.

BB05 [0004]  1  0  3 BB12                  0    [008..00B)-> BB07(1)                 (callf ) T0 H3   try {       i rare keepBB13 [0012]  1  0  3 BB07                  0    [???..???)-> BB14(1)                 (callfr) T0 H3   }           i rare internalBB06 [0005]  1  1  0                       0    [00B..00F)-> BB07(1)                 (callf ) T1 H0   catch {     i rare keepBB15 [0014]  1  1  0 BB07                  0    [???..???)-> BB16(1)                 (callfr) T1 H0   } }         i rare internalBB07 [0006]  3  2  1 BB05,BB06             0    [00F..012)-> BB13(0.5),BB15(0.5)     (finret) T2 H1 finally { } } i rare keep

Here T0 is empty and we're trying to remove it and H0.

But there is a pred edge into the middle of H0/BB15 from an outside region (BB07), which is not something my simple-minded handler removal code supports yet.

/azp run runtime-coreclr jitstress

With this bothTest1 andTest2 can produce optimal codegen now

voidTest1(){varx=42;varz=52;try{vary=14;z=x+y;}finally{Console.WriteLine(z);}}voidTest2(){varx=42;varz=52;try{vary=14;z=x+y;}catch{}Console.WriteLine(z);}

codegen:

G_M27646_IG01:  ;; offset=0x0000;; size=0 bbWeight=1 PerfScore 0.00G_M27646_IG02:  ;; offset=0x0000movedi,56;; size=5 bbWeight=1 PerfScore 0.25G_M27646_IG03:  ;; offset=0x0005       tail.jmp[System.Console:WriteLine(int)];; size=6 bbWeight=1 PerfScore 2.00

But the codegen ofTest3 which has bothcatch andfinally is still not optimal:

voidTest3(){varx=42;varz=52;try{vary=14;z=x+y;}catch{}finally{Console.WriteLine(z);}}

codegen:

G_M27646_IG01:  ;; offset=0x0000pushrbpsubrsp,16learbp,[rsp+0x10]mov      qword ptr[rbp-0x10],rsp;; size=14 bbWeight=1 PerfScore 2.75G_M27646_IG02:  ;; offset=0x000Emov      dword ptr[rbp-0x04],52;; size=7 bbWeight=1 PerfScore 1.00G_M27646_IG03:  ;; offset=0x0015mov      dword ptr[rbp-0x04],56;; size=7 bbWeight=1 PerfScore 1.00G_M27646_IG04:  ;; offset=0x001Cmovedi,56call[System.Console:WriteLine(int)]nop;; size=12 bbWeight=1 PerfScore 3.50G_M27646_IG05:  ;; offset=0x0028addrsp,16poprbpret;; size=6 bbWeight=1 PerfScore 1.75G_M27646_IG06:  ;; offset=0x002Epushrbpsubrsp,16movrbp, qword ptr[rdi]mov      qword ptr[rsp],rbplearbp,[rbp+0x10];; size=16 bbWeight=0 PerfScore 0.00G_M27646_IG07:  ;; offset=0x003Emovedi, dword ptr[rbp-0x04]call[System.Console:WriteLine(int)]nop;; size=10 bbWeight=0 PerfScore 0.00G_M27646_IG08:  ;; offset=0x0048addrsp,16poprbpret;; size=6 bbWeight=0 PerfScore 0.00

/cc:@AndyAyersMS

But the codegen ofTest3 which has bothcatch andfinally is still not optimal:

This turns into a try-catch inside a try-finally. We remove the try-catch and convert the try-finally to a try-fault. But we haven't yet implemented (empty)try-fault removal.

Seems like this is actually simple to handle; I'll put up a PR shortly.