Fix issue with devirtualization and tailcalls

[briansull]

When performing devirtualization we can not do both an unboxing optimization and a tail call optimization

• Explicit tail calls are now checked for and blocked from performing an unboxing operation in impDevirtualizeCall.
• If late devirtualization calls impDevirtualizeCall with an IMPLICIT_TAILCALL we will clear this flag if we decide to perform the unboxing operation.

[briansull]

@AndyAyersMS FYI

[AndyAyersMS]

You should make it clearer that this restriction is for explicit tail calls only, where presumably the IL producer is confident that at the point of the explicit tail call there aren't any live references to the caller frame, and if we undo the box, we will introduce one.

And I think this could also happen for late devirt though it would require a different kind of test case.

Seems like you could just check for GTF_CALL_M_EXPLICIT_TAILCALL to inhibit the box undo transform, instead of passing in extra info, and handle it more cleanly and more generally.

[briansull]

The flag GTF_CALL_M_EXPLICIT_TAILCALL is currently not yet set by the importer when we reach this method.
It currently gets set here: importer.cpp line 8753 and the call to devirtualize is on line 8597.

[briansull]

The IL for the method with the tailcall is:

****** START compiling Program:Test(int):ref:this (MethodHash=f85425b1)
IL to import:
IL_0000  03                ldarg.1     
IL_0001  8c 04 00 00 01    box          0x1000004
IL_0006  fe 14             tail.       
IL_0008  6f 03 00 00 0a    callvirt     0xA000003
IL_000d  2a                ret         

This IL doesn't contain any live references to the caller frame, however the JIT compiler introduces one via:

Compiler::impImportAndPushBox -- handling BOX(value class) via inline allocate/copy sequence
lvaGrabTemp returning 3 (V03 tmp1) called for Single-def Box Helper.

and then we unbox this, which introduces the live references to the caller frame, 

Source code:

using System;
using System.Runtime.CompilerServices;

class Program
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    public String Test(int val)
    {
        return  /* tailcall */ ((Object) val).ToString();
    }

    static void Main(string[] args)
    {
        Program p = new Program();

        String result = p.Test(42);
        Console.WriteLine("result = " + result);
    }
}

[AndyAyersMS]

Hmm, ok. We should still fix the late devirt path, and that one needs to work with the call flags. So we need to adapt for one convention or the other.

If it was me I'd probably handle this by passing in a bool isExplicitTailCall and returning a bool result indicating if we unboxed, and then adapt the two call sites to suit.

[briansull]

@AndyAyersMS @jashook PTAL

[briansull]

This assignment was redundant (see line 8736 above)

[briansull]

@dotnet-bot Test Ubuntu x64 Checked Innerloop Build and Test

[briansull]

@dotnet-bot test Ubuntu x64 Checked Innerloop Build and Test (Jit - TieredCompilation=0)

[AndyAyersMS]

Looks good overall, just two small nits.

Would be nice to have a test case here too (probably an IL case...)

[AndyAyersMS]

Typo: explcit

[AndyAyersMS]

This is no longer [in/out] -- also rename to isExplictTailCall

[briansull]

Yes, I do have an IL test case that I will add

[jashook]

Is the compiler global isTailCall used?

[briansull]

This parameter is used and it is also renamed as isExplicitTailCall

[briansull]

@dotnet-bot Test OSX10.12 x64 Checked Innerloop Build and Test

[briansull]

@dotnet-bot Test Windows_NT arm Cross Checked Innerloop Build and Test