JIT: enable implicit tail calls from inlined code #9405

AndyAyersMS · 2017-02-08T02:36:24Z

Inlines of calls from implicit tail call sites should allow recognition
of inlinee implicit tail call sites.

The jit recognizes implicit tail call sites during importation,
but the inlinee compiler instance did not have compTailCallOpt set
and so never recognized these instances. Fix this and update the logic
to detect the transitively implicit tail calls.

Now that these sites are recognized, morph needs a fix to tunnel through
repeated casts for tail calls, since each level of inlining might add a
cast. All these casts should be identical.

Note under R2R tail calls are not yet recognized (see ZapInfo::canTailCall).

Closes #9349.

AndyAyersMS · 2017-02-08T02:38:00Z

@JosephTremoulet PTAL
cc @dotnet/jit-contrib

Jit-diff data (only diffs in corelib because R2R currently inhibits tail calls):

Total bytes of diff: 798 (0.01 % of base)
    diff is a regression.
Total byte diff includes 0 bytes from reconciling methods
        Base had    0 unique methods,        0 unique bytes
        Diff had    0 unique methods,        0 unique bytes
Top file regressions by size (bytes):
         798 : System.Private.CoreLib.dasm (0.02 % of base)
1 total files with size differences.
Top method regessions by size (bytes):
          47 : System.Private.CoreLib.dasm - System.Diagnostics.Tracing.ActivityTracker:OnStart(ref,ref,int,byref,byref,int):this
          40 : System.Private.CoreLib.dasm - System.Diagnostics.Tracing.ActivityTracker:OnStop(ref,ref,int,byref):this
          27 : System.Private.CoreLib.dasm - System.StubHelpers.NullableMarshaler:ConvertToNative(byref):long (9 methods)
          20 : System.Private.CoreLib.dasm - System.Security.Permissions.FileIOPermission:AddPathList(int,int,ref,bool,bool,bool):this
          12 : System.Private.CoreLib.dasm - System.Reflection.Emit.TypeBuilder:SetInterfaces(ref):this
Top method improvements by size (bytes):
         -34 : System.Private.CoreLib.dasm - System.Reflection.Emit.SignatureHelper:AddOneArgTypeHelperWorker(ref,bool):this
         -10 : System.Private.CoreLib.dasm - Decoder:.ctor(ref):this (2 methods)
          -5 : System.Private.CoreLib.dasm - UTF32Decoder:.ctor(ref):this
          -5 : System.Private.CoreLib.dasm - System.Nullable`1[Guid][System.Guid]:ToString():ref:this
          -5 : System.Private.CoreLib.dasm - System.Nullable`1[TimeSpan][System.TimeSpan]:ToString():ref:this
384 total methods with size differences.

AndyAyersMS · 2017-02-08T07:10:27Z

Tail call opts are not enabled in debug builds, so even w/o looking in the logs, the ARM64 failures are almost certainly unrelated. Looking at the logs shows some kind of scripting issue.

18:56:27 d:\j\workspace\arm64_cross_c---f41ee988>python tests\scripts\arm64_post_build.py -repo_root d:\j\workspace\arm64_cross_c---f41ee988 -arch arm64 -build_type checked -scenario default -key_location C:\tools\key.txt 
18:56:27 Traceback (most recent call last):
18:56:27   File "tests\scripts\arm64_post_build.py", line 311, in <module>
18:56:27     main(args)
18:56:27   File "tests\scripts\arm64_post_build.py", line 254, in main
18:56:27     repo_root, arch, build_type, scenario, key_location, force_update = validate_args(args)
18:56:27   File "tests\scripts\arm64_post_build.py", line 228, in validate_args
18:56:27     validate_arg(key_location, lambda item: os.path.isfile(item))
18:56:27   File "tests\scripts\arm64_post_build.py", line 218, in validate_arg
18:56:27     raise Exception("Argument: %s is not valid." % (arg))
18:56:27 Exception: Argument: C:\tools\key.txt is not valid.

JosephTremoulet

LGTM

JosephTremoulet · 2017-02-08T13:15:27Z

src/jit/compiler.cpp

+    CLANG_FORMAT_COMMENT_ANCHOR;
+
+#if FEATURE_TAILCALL_OPT
+    opts.compTailCallLoopOpt = true;


Would it be possible/interesting (at some point in the future) to recognize tail calls back to an inlinee and make them loops?

Yes, it would be possible. We already track the ancestral inline context for each call site, so we can tell when a call site recursively invokes an inlinee. What we'd need in addition is the following:

track the logical entry point for the inlinee in the inline context, so we know where to target the loop branch.

disable direct sub for inlinees in tail position, since the arguments are now potentially starg.

With that I think we could generalize the loop tail call opt to handle inlined cases, and I think a tail call loop opt is potentially much more impactful then a tail call alone.

One more thing: we currently won't tail call if the root method is noinline, but that block doesn't make sense for these inlinee loop tail call opts, so we should track calls in tail position in addition to calls eligible to be made into tail calls.

sivarv · 2017-02-08T15:09:01Z

Looks good.
Trying ngen diffs on desktop will provide another measure of CQ impact.
On desktop, tail call differences could lead to app compat issues (we had an instance of GetCallingAssembly() failure during 4.6 sign-off time). We can be conservative and enable this only for CoreCLR or should remember to disable this if there are any app compat failures on desktop due to this.

AndyAyersMS · 2017-02-08T15:52:48Z

@JosephTremoulet I vaguely recall you had a way of getting fragile ngen codegen in jit-diffs. If not, we should potentially add that as an option. Or get SPMI online and ensure it has a proper mix of jit/ngen/r2r instances.

@sivarv good point about desktop. Do you recall what the fix was for the app compat issue?

JosephTremoulet · 2017-02-08T16:02:44Z

@JosephTremoulet I vaguely recall you had a way of getting fragile ngen codegen in jit-diffs. If not, we should potentially add that as an option

No, I've just used jit-produced asm when I wanted to be extra sure I was looking at diffs matching benchmark execution. You may be remembering that I opened dotnet/jitutils#75, but I haven't implemented it. It should be trivial to implement if crossgen has a --fragile flag, but if it has one it seems to be hidden...

Or get SPMI online and ensure it has a proper mix of jit/ngen/r2r instances.

That would be great!


        JIT: enable implicit tail calls from inlined code

Inlines of calls from implicit tail call sites should allow recognition of inlinee implicit tail call sites. The jit recognizes implicit tail call sites during importation, but the inlinee compiler instance did not have compTailCallOpt set and so never recognized these instances. Fix this and update the logic to detect the transitively implicit tail calls. Now that these sites are recognized, morph needs a fix to tunnel through repeated casts for tail calls, since each level of inlining might add a cast. All these casts should be identical. Note under R2R tail calls are not yet recognized (see ZapInfo::canTailCall). Closes #9349.

AndyAyersMS · 2017-02-08T16:17:48Z

crossgen has a /FragileNonVersionable option for this, though it doesn't show up in the help.

I would patch jit-dasm/jit-diff but I'm stuck on an older version....

sivarv · 2017-02-08T16:18:37Z

@AndyAyersMS - desktop appcompat failure was due to a particular class of implicit tail calls (the ones with shared return). See FEATURE_TAILCALL_OPT_SHARED_RETURN in jit.h, it is defined as 1 for CoreCLR and 0 on desktop.

AndyAyersMS · 2017-02-08T17:51:26Z

Tried running desktop SPMI. Unfortunately it fails on exactly the methods we'd like to examine, since there are new calls to canTailCall that aren't resolvable by the cached data. So will try ngen or PMI diffs instead.

AndyAyersMS · 2017-02-08T22:46:36Z

Desktop also running into asserts because for desktop FEATURE_TAILCALL_OPT_SHARED_RETURN is disabled, and it's not guaranteed that inline implicit tail call sites are in a BBJ_RETURN block (they may be in a predecessor block that falls through or jumps to the return). It seems prudent for now to only enable recognition of inline implicit tail calls under this feature.

Which means, they won't be recognized on desktop....


        enable only if shared returns are supported

AndyAyersMS · 2017-02-09T20:43:14Z

Updated (& rebased) to only kick in if we support shared returns. Verified no diff on desktop.

sivarv · 2017-02-10T01:03:30Z

Looks good.


        JIT: enable implicit tail calls from inlined code (dotnet#9405)

Inlines of calls from implicit tail call sites should allow recognition of inlinee implicit tail call sites. The jit recognizes implicit tail call sites during importation, but the inlinee compiler instance did not have compTailCallOpt set and so never recognized these instances. Fix this and update the logic to detect the transitively implicit tail calls. Now that these sites are recognized, morph needs a fix to tunnel through repeated casts for tail calls, since each level of inlining might add a cast. All these casts should be identical. Note under R2R tail calls are not yet recognized (see ZapInfo::canTailCall). Enable only under FEATURE_TAILCALL_OPT_SHARED_RETURN since the inline tail call sites are not likely to be in BBJ_RETURN blocks. Closes dotnet#9349.


        JIT: enable implicit tail calls from inlined code (dotnet#9405)

Inlines of calls from implicit tail call sites should allow recognition of inlinee implicit tail call sites. The jit recognizes implicit tail call sites during importation, but the inlinee compiler instance did not have compTailCallOpt set and so never recognized these instances. Fix this and update the logic to detect the transitively implicit tail calls. Now that these sites are recognized, morph needs a fix to tunnel through repeated casts for tail calls, since each level of inlining might add a cast. All these casts should be identical. Note under R2R tail calls are not yet recognized (see ZapInfo::canTailCall). Enable only under FEATURE_TAILCALL_OPT_SHARED_RETURN since the inline tail call sites are not likely to be in BBJ_RETURN blocks. Closes dotnet#9349.

dnfclas added the cla-already-signed label Feb 8, 2017

AndyAyersMS added area-CodeGen optimization labels Feb 8, 2017

JosephTremoulet approved these changes Feb 8, 2017

View changes

enable only if shared returns are supported

Loading status checks…

3387edc

AndyAyersMS force-pushed the AndyAyersMS:InlineImplicitTailCalls branch from 9af0cf8 to 3387edc Feb 9, 2017

AndyAyersMS referenced this pull request Feb 11, 2017

JIT assert breaks Windows Arm32 official builds #9536

Closed

sivarv referenced this pull request Feb 14, 2017

[JitStress=2] Assertion failed '!call->IsImplicitTailCall() || !gtIsRecursiveCall(call)' in fgMorphCallInlineHelper() #9568

Closed

RussKeldorph referenced this pull request Feb 17, 2017

[JitStress=1] Assert failure(PID 1148 [0x0000047c], Thread: 3244 [0x0cac]): Assertion failed 'stmtOper == GT_RETURN || stmtOper == GT_ASG' #9641

Closed

AndyAyersMS referenced this pull request Mar 9, 2017

RyuJIT: tail call stress assert in importer on Linux #10047

Open

sandreenko referenced this pull request May 30, 2017

CoreRT shows a problem with inlined tail calls. #11983

Closed

karelz modified the milestone: 2.0.0 Aug 28, 2017

dotnet/coreclr

JIT: enable implicit tail calls from inlined code #9405

JIT: enable implicit tail calls from inlined code #9405

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

JosephTremoulet left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

sivarv commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

JosephTremoulet commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

sivarv commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 9, 2017

This comment has been minimized.

sivarv commented Feb 10, 2017

dotnet/coreclr

Join GitHub today

JIT: enable implicit tail calls from inlined code #9405

Conversation

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

JosephTremoulet left a comment

This comment has been minimized.

JosephTremoulet Feb 8, 2017

This comment has been minimized.

AndyAyersMS Feb 8, 2017

This comment has been minimized.

AndyAyersMS Feb 8, 2017

This comment has been minimized.

sivarv commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

JosephTremoulet commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

sivarv commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 8, 2017

This comment has been minimized.

AndyAyersMS commented Feb 9, 2017

This comment has been minimized.

sivarv commented Feb 10, 2017