ARM64: redundant store/load in generated constructor code

[DavidWBrooks]

Description

In an admittedly small sample, every constructor generates code like this (clipped from Visual Studio but windbg shows the same code). This is from App.xaml.cs in a starter app using the VS2022 WinUI template, which is an easy repro.

_window = new MainWindow();
00007FFA2CE9C0BC mov x0,#0x48F0
00007FFA2CE9C0C0 movk x0,#0x2DA7,lsl #0x10
00007FFA2CE9C0C4 movk x0,#0x7FFA,lsl #0x20
00007FFA2CE9C0C8 bl CLRStub[JumpStub]@00007FFA2CE60128 (07FFA2CE60128h)
00007FFA2CE9C0CC stur x0,[fp,#-0x18]
00007FFA2CE9C0D0 ldur x0,[fp,#-0x18]
00007FFA2CE9C0D4 bl WinUI.MainWindow..ctor() (07FFA2DA68F48h)

Similar code can be found in WPF, Forms, and a Console app - except Console uses str/ldr, and so does WinUI if I add other constructors. I'm new to ARM64, but I don't see a difference between stur and str for a 64-bit register.

Just to pile on, if the new() is the first parameter to a function call that immediately follows, even the stur is superfluous (although I realize that may not be a peephole optimization).

This is similar to the redundant code found by @kunalspathak over various iterations, but he didn't list this one. And I'd understand if it doesn't happen frequently enough to optimize.

I can see that the stur "belongs" to the previous instruction, and the ldur to the following one, which is why this is probably a peephole fix.

Configuration

Windows 11 build 26200.7462
.NET 9.0.11
ARM64
Visual Studio 2022 Community

Regression?

Not known. The same happens in .NET 8, at any rate.

[JulieLeeMSFT]

Simple optimization so putting it to .NET 11 but we might push out.

[EgorBo]

Can you please provide a full snippet/project we can take a look? Are you sure it's not a Tier0 or even debug codegen?

[DavidWBrooks]

Release Build, but what is "Tier0"?

As I said, you can see the snippet above by using VS 2022 Community to create a new "WinUI Blank App (Packaged), build and run arm64 Release, and inspect the code around the MainWindow constructor. Attached is a version in which I added an artificial constructor to a click callback. It actually stores and then reloads x0 and x1 one after the other. I didn't see that before and it may complicate the keyhole inspection.

WinUI start.zip

[EgorBo]

Release Build, but what is "Tier0"?

.NET's JIT has multiple tiers, in Tier0 it doesn't use optimizations (most of them). You may workaround it by applying [MethodImpl(MethodImplOptions.AggressiveOptimization)] so it goes straight to the last tier.
Also, I believe, by default, Visual Studio deoptimizes code around breakpoints, so if you look at the disasm in VS's Dissamebly window, you most likely look at debug codegen (even under Release).