Swapping with tuple deconstruction compiles to inferior IL code compared to using a temporary variable

[hamarb123]

Description

Swapping / reordering variables compiles to slower IL code when using tuple destruction than a temporary variable.
I tested this in Release mode.

The following C# code

int x = 1;
int y = 2;
int z = 3;
(x, y)=(y, x);
Console.WriteLine((x,y,z)); //this line is to stop compiling out the variables

should be equivalent in IL output to

int x = 1;
int y = 2;
int z = 3;
int temp = x;
x = y;
y = temp;
Console.WriteLine((x,y,z)); //this line is to stop compiling out the variables

, but the first compiles to:

// Code size       31 (0x1f)
.maxstack  3
.locals init (int32 V_0,
         int32 V_1,
         int32 V_2,
         int32 V_3)
ldc.i4.1
stloc.0
ldc.i4.2
stloc.1
ldc.i4.3
stloc.2
ldloc.1
ldloc.0
stloc.3
stloc.0
ldloc.3
stloc.1
ldloc.0
ldloc.1
ldloc.2
newobj     instance void valuetype [System.Runtime]System.ValueTuple`3<int32,int32,int32>::.ctor(!0,
                                                                                                           !1,
                                                                                                           !2)
box        valuetype [System.Runtime]System.ValueTuple`3<int32,int32,int32>
call       void [System.Console]System.Console::WriteLine(object)
ret

and the second compiles to

// Code size       29 (0x1d)
.maxstack  3
.locals init (int32 V_0,
         int32 V_1,
         int32 V_2)
ldc.i4.1
stloc.0
ldc.i4.2
stloc.1
ldc.i4.3
stloc.2
ldloc.0
ldloc.1
stloc.0
stloc.1
ldloc.0
ldloc.1
ldloc.2
newobj     instance void valuetype [System.Runtime]System.ValueTuple`3<int32,int32,int32>::.ctor(!0,
                                                                                                           !1,
                                                                                                           !2)
box        valuetype [System.Runtime]System.ValueTuple`3<int32,int32,int32>
call       void [System.Console]System.Console::WriteLine(object)
ret

With the essential code being for (1):

ldloc.1
ldloc.0
stloc.3
stloc.0
ldloc.3
stloc.1

, and for (2):

ldloc.0
ldloc.1
stloc.0
stloc.1

I did test this on .NET 5 locally, but also on an online .NET 6 compiler at https://sharplab.io/, which uses a very recent version.
I also imagine that a similar thing happens for other variants, such as:

(x, y) = (x, x);
(x, y, z, w) = (w, y, z, x);

etc.
Surely these destruction assignments should be as simple as ld all of the variables, and then st them all (as long as there's not too many).
Interestingly, the tuple destruction code essentially uses a temporary variable in IL, whereas the temporary variable code eliminates it.
Not sure if this belongs on roslyn or on here.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[Wraith2]

If you check the JIT asm on sharplab you'll find they have the same output.

[hamarb123]

Yes, that makes sense, but I still think that we should produce the best IL possible, since it will take less time to JIT and will be smaller. Especially since it seems that they bothered to do it for C# temporary variable so it should be easier to implement if it's already implemented elsewhere, and I'm sure that they had a good reason to do it for C# temporary variable.

[Joe4evr]

but I still think that we should produce the best IL possible

While that may be reasonable for you to assume, the only responsibility the compiler has is producing correct IL. Producing optimized IL would require much more analysis, most of which can't be done if you're compiling something like a class library (no entry point).

• It's not always clear what "optimal" IL looks like. One must anticipate the capabilities and limitations of the downstream code generator.

- #15929 (comment)

since it will take less time to JIT and will be smaller

And your metrics for this statement are where?

[hamarb123]

I see your point re making correct IL, that's probably fair enough then, but this optimisation has nothing to do whether it's a class library or not, it's just swapping locals, it doesn't rely on any library at all, or the possible behaviour differences between a library and an executable (which shouldn't be different if you ask me since you can reference it even if it has an entry point).
Also, by smaller, I meant the IL is smaller, which it is.
I can take a good guess with the JITting time since it is just the same instruction, but more unnecessary copies of it.