Why are there hidden copies created by the compiler when comparing C# Value Tuples with ==?

Question

Equality between Value Tuple types was introduced in C# 7.3. It allows code like this:

var x = (1, 2);
var y = (1, 2);

if(x == y) ...

This works fine and gives the correct result. However, the compiler introduces hidden copies of the tuple objects, and compares those instead, giving the equivalent of this:

var V_3 = x;
var V_4 = y;
if(V_3.Item1 == V_4.Item1 && V_3.Item2 == V_4.Item2) ...

Are V_3 and V_4 just defensive copies? If so, what are they defending against?

This is the smallest e.g I could come up with, but I've tried with user-defined structs, and method returns/properties as tuple members as well with similar (not always identical) output.

I'm using v5.0.202 of the .Net SDK and C# v9, but have seen this behavior since .Net Core 3.

Answer 1

The answer is that MSIL, the intermediate language you're decompiling back into C#, is a stack-based language, and stack-based languages have difficulty referencing what's not at the very top of the stack. So instead you can add a local variable and store results you can't easily reach.

And the reason why this seeming inefficiency isn't getting optimized out is that it simply doesn't matter. When JITed to native code, the compiler emits direct comparisons and a jump like you'd expect:

    var rng = new Random();
    var v1=(rng.Next(), rng.Next());
    var v2=(rng.Next(), rng.Next());
    
    return v1 == v2;

generates (skipping the initialization and restoring the stack in the prologue):

L004f: cmp edi, ebp
L0051: jne short L0064
L0053: cmp ebx, eax
L0055: sete al                // == && ==?
L0058: movzx eax, al          // return true && 2nd equality result
L0063: ret
L0064: xor eax, eax           // return false
L006e: ret