具有绝对返回路径的方法如何内联？

Question

我主要使用C#开发,但我认为这个问题也适用于其他语言.
此外,似乎这里有很多代码,但问题很简单.

根据我的理解,内联是编译器(在C#是虚拟机的情况下)通过在调用方法的每个位置插入方法体来替换方法调用.

假设我有以下程序:

static Main()
{        
    int number = 7;
    bool a;
    a = IsEven(number);
    Console.WriteLine(a);
}

......方法的主体IsEven:

bool IsEven(int n) 
{
    if (n % 2 == 0) // Two conditional return paths
        return true;
    else
        return false;
}

我可以理解在内联方法后代码的样子:

static Main()
{
    int number = 7;
    bool a;
    if (number % 2 == 0)
        a = true;
    else
        a = false;
    Console.WriteLine(a); // Will print true if 'number' is even, otherwise false
}

一个明显简单而正确的程序.

但是,如果我调整IsEven一点点的身体,包括一个绝对的返回路径......

bool IsEven(int n)
{
    if (n % 2 == 0)
        return true;
    return false; // <- Absolute return path!
}

在某些情况下,我个人更喜欢这种风格.一些折射工具甚至可能会建议我将第一个版本更改为这个版本 - 但是当我试图想象这个方法在内联时的样子时我感到难过.
如果我们内联方法的第二个版本:

static Main()
{
    int number = 7;
    bool a;
    if (number % 2 == 0)
        a = true;
    a = false;
    Console.WriteLine(a); // Will always print false!
}

要问的问题:
编译器/虚拟机如何处理内联具有绝对返回路径的方法？
这样的事情似乎不太可能真正阻止方法内联,所以我想知道如何处理这些事情.也许内联的过程并不像这样简单？也许一个版本更有可能被VM内联？

编辑: 分析两种方法(以及第一种方法的手动内联)显示性能没有差异,因此我只能假设这两种方法都以相同或相似的方式内联并工作(至少在我的VM上).
此外,这些方法非常简单并且看起来几乎可以互换,但是具有绝对返回路径的复杂方法可能更难以更改为没有绝对返回路径的版本.

Answer 1

它可能很难解释JITter在内联时所做的事情 - 它不会使C#代码变为内联 - 它将(总是？)处理生成的字节(编译版本) - 以及"工具"在生成汇编代码时(实际的机器代码字节)比C#(或者IL的代码)更精细.

也就是说,通过考虑break关键字,您可以在C#术语中了解它的工作原理.

考虑可能性,即每个不重要的内联函数都包含在while (true)循环(或do while(false)循环)中 - 并且每个源返回都被转换为一localVar = result; break;组语句.然后你得到这样的东西:

static Main() 
{ 
    int number = 7; 
    bool a; 
    while (true)
    {
       if (number % 2 == 0) 
       {
          a = true; 
          break;
        }
        a = false; 
        break;
    }

    Console.WriteLine(a); // Will always print the right thing! Yey!
}

类似地,在生成程序集时,你会看到很多jmps被生成 - 这些是break语句的道德等价物,但它们更灵活(将它们视为匿名的getos或其他东西).

所以你可以看到,抖动(以及编译为本机的任何编译器)都有很多可以用来做"正确的事情"的工具.