Compiler using get and set Methods over BackingFields

[IAmTheCShark]

Maybe my understanding of this is not good enough, but can't the compiler use BackingFields instead of properties within the same class?
E.g. right now, this code

using System;

public class _
{
    private int P {get;set;} = 7;
    private int F = 6;
    private void Run()
    {
        Console.Write(F * P);
    }
}

Results in the following compiler generated C# code (according to https://sharplab.io)

[CompilerGenerated]
private int <P>k__BackingField = 7;

private int F = 6;

private int P
{
    [CompilerGenerated]
    get
    {
        return <P>k__BackingField;
    }
    [CompilerGenerated]
    set
    {
        <P>k__BackingField = value;
    }
}

private void Run()
{
    Console.Write(F * P);
}

But can't the Run-method look like this? (Inlining the get-method)

private void Run() 
{
    Console.Write(F * <P>k__BackingField);
}

Am I wrong here or is it just not a big enough deal to change or is the magic happening somewhere else?

[YairHalberstadt]

The JIT is responsible for optimisations such as inlining.
Roslyn only make optimisations that the Jit would struggle to make.

[theunrepentantgeek]

There are post compilation tools (one that I've used is PostSharp) that can rewrite property implementations after the compiler has done its job.

It would therefore be a breaking change if the C# compiler changed to directly reference the backing field instead of calling the property getter, as any rewritten property getter would be bypassed.

[YairHalberstadt]

Also, for future reference this type of issue probably belongs on the Roslyn repo.

[IAmTheCShark]

@YairHalberstadt yeah i just noticed this is csharplang. My bad.

[YairHalberstadt]

No problem

[ufcpp]

IIRC, this is by design, by C# language spec.

struct Sample
{
    // get-only auto property was introduced in C# 6.0
    public int X { get; }

    public int Y { get; set; }

    public Sample(int x, int y)
    {
        // All fields must be initialized before accessing function members.
        // To allow this property initialization, X = x should be translated into <X>k__BackingField = x.
        X = x;

        // This could not compile with C# 5.0 or earlier
        // but can compile with 6.0 or later due to translation into <Y>k__BackingField = y.
        Y = y;
    }
}

Private access to auto-implemented properties may be allowed to optimized by C# compiler, not by JIT.

[yaakov-h]

@ufcpp I actually read that as the other way around, the JIT can but the compiler cannot:

In particular, when a property is non-virtual and contains only a small amount of code, the execution environment may replace calls to accessors with the actual code of the accessors.

For constructors, the spec defines the compiler behaviour you're observing:

Just like a readonly field, a getter-only auto-property can also be assigned to in the body of a constructor of the enclosing class. Such an assignment assigns directly to the readonly backing field of the property.