Question

I mostly develop using C#, but I think this question might be suitable for other languages as well.
Also, it seems like there is a lot of code here but the question is very simple.

Inlining, as I understand it, is the compiler (in the case of C# the Virtual Machine) replacing a method call by inserting the body of the method in every place the method was called from.

Let’s say I have the following program:

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

… the body of the method IsEven:

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

I could understand how code will look like after inlining the method:

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
}

An obviously simple and correct program.

But if I tweak the body of IsEven a little bit to include an absolute return path…

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

I personally like this style a bit more in some situations. Some refractoring tools might even suggest that I do change the first version to look like this one – but when I tried to imagine how this method would look like when it’s inlined I was stumped.
If we inline the second version of the method:

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

The question to be asked:
How does the Compiler / Virtual Machine deal with inlining a method that has an absolute return path?
It seems extremely unlikely that something like this would really prevent method inlining, so I wonder how such things are dealt with. Perhaps the process of inlining isn’t as simple as this? Maybe one version is more likely to being inlined by the VM?

Edit:
Profiling both methods (and manual inlining of the first one) showed no difference in performance, so I can only assume that both methods get inlined and work in the same or similar manner (at least on my VM).
Also, these methods are extremely simple and seem almost interchangeable, but complex methods with absolute return paths might be much more difficult to change into versions without absolute return paths.

Answer 1

It’s can be kind of hard to explain what the JITter does when it inlines – it does not chage the C# code to do the inlining – it will (always?) work on the produced bytes (the compiled version) – and the “tools” you have when producing assembly-code (the actual machine code bytes) are much more fine grained than what you have in C# (or IL for that matter).

That said, you can have an idea of how it works, in C# terms by considering the break keyword..

Consider the possiblity that every inline function that’s not trivial is enclosed in a while (true) loop (or do while(false) loop) – and that every source return is translated to a localVar = result; break; set of statements. Then you get something like this:

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!
}

Similarly, when producing assembly, you will see A LOT of jmps being generated – those are the moral equivalent of the break statements, but they are MUCH more flexible (think about them as anonymous gotos or something).

So you can see, the jitter (and any compiler that compiles to native) has A LOT of tools at hand it can use to do “the right thing”.