JIT: Support bitwise field insertions for call arguments #115977

jakobbotsch · 2025-05-25T18:05:05Z

Add support using bitwise operations to reconstruct registers passed into calls from multiple promoted fields. Remove the IR invariant that FIELD_LIST args must always map cleanly to registers; instead, any FIELD_LIST is allowed for register-only arguments before lowering, and lowering takes care to normalize them into a handled shape.

fgTryMorphStructArg is changed to take advantage of this by now producing FIELD_LIST even when a promoted arg does not match the target ABI. Support in physical promotion will be added in a follow up.

Split arguments are not handled and retain the old IR invariant of requiring registers and stack slots to make cleanly from FIELD_LIST.

win-x64 examples:

static void Foo(int x)
{
    Use<int?>(x);
    Use<int?>(5);
    Use<int?>(null);
}

 G_M7200_IG02:  ;; offset=0x0004
-       mov      byte  ptr [rsp+0x20], 1
-       mov      dword ptr [rsp+0x24], ecx
-       mov      rcx, qword ptr [rsp+0x20]
+       mov      ecx, ecx
+       shl      rcx, 32
+       or       rcx, 1
        call     [Program:Use(System.Nullable`1[int])]
-       mov      dword ptr [rsp+0x24], 5
-       mov      rcx, qword ptr [rsp+0x20]
+       mov      rcx, 0x500000001
        call     [Program:Use(System.Nullable`1[int])]
-       mov      byte  ptr [rsp+0x20], 0
        xor      ecx, ecx
-       mov      dword ptr [rsp+0x24], ecx
-       mov      rcx, qword ptr [rsp+0x20]
-						;; size=55 bbWeight=1 PerfScore 14.25
+						;; size=34 bbWeight=1 PerfScore 7.50

 G_M7200_IG03:
        add      rsp, 40
        tail.jmp [Program:Use(System.Nullable`1[int])]
 						;; size=10 bbWeight=1 PerfScore 2.25

static void Foo(int x, float y)
{
    Use((x, y));
}

 G_M42652_IG01:  ;; offset=0x0000
-       push     rax
-						;; size=1 bbWeight=1 PerfScore 1.00
+						;; size=0 bbWeight=1 PerfScore 0.00

 G_M42652_IG02:
-       mov      dword ptr [rsp], ecx
-       vmovss   dword ptr [rsp+0x04], xmm1
-       mov      rcx, qword ptr [rsp]
+       vmovd    eax, xmm1
+       shl      rax, 32
+       mov      ecx, ecx
+       or       rcx, rax
 						;; size=13 bbWeight=1 PerfScore 3.00

 G_M42652_IG03:
-       add      rsp, 8
        tail.jmp [Program:Use[System.ValueTuple`2[int,float]](System.ValueTuple`2[int,float])]

A win-arm64 example:

static void Foo(int[] arr)
{
    Use(arr.AsMemory());
}

 G_M33990_IG01:
-            stp     fp, lr, [sp, #-0x20]!
+            stp     fp, lr, [sp, #-0x10]!
             mov     fp, sp
-            str     xzr, [fp, #0x10]	// [V03 tmp2]
-						;; size=12 bbWeight=1 PerfScore 2.50
+						;; size=8 bbWeight=1 PerfScore 1.50

 G_M33990_IG02:
             cbz     x0, G_M33990_IG04
 						;; size=4 bbWeight=1 PerfScore 1.00

 G_M33990_IG03:
-            str     x0, [fp, #0x10]	// [V07 tmp6]
-            str     wzr, [fp, #0x18]	// [V08 tmp7]
-            ldr     w0, [x0, #0x08]
-            str     w0, [fp, #0x1C]	// [V09 tmp8]
+            ldr     w1, [x0, #0x08]
             b       G_M33990_IG05
-						;; size=20 bbWeight=0.50 PerfScore 3.50
+						;; size=8 bbWeight=0.50 PerfScore 2.00

 G_M33990_IG04:
-            str     xzr, [fp, #0x10]	// [V07 tmp6]
-            str     xzr, [fp, #0x18]
-						;; size=8 bbWeight=0.50 PerfScore 1.00
+            mov     x0, xzr
+            mov     w1, wzr
+						;; size=8 bbWeight=0.50 PerfScore 0.50

 G_M33990_IG05:
-            ldp     x0, x1, [fp, #0x10]	// [V03 tmp2], [V03 tmp2+0x08]
-            movz    x2, #0xD920      // code for Program:Use[System.Memory`1[int]](System.Memory`1[int])
-            movk    x2, #0x4590 LSL #16
+            mov     w1, w1
+            lsl     x1, x1, #32
+            movz    x2, #0xD950      // code for Program:Use[System.Memory`1[int]](System.Memory`1[int])
+            movk    x2, #0x4592 LSL #16
             movk    x2, #0x7FFE LSL #32
             ldr     x2, [x2]
-						;; size=20 bbWeight=1 PerfScore 7.50
+						;; size=24 bbWeight=1 PerfScore 6.00

 G_M33990_IG06:
-            ldp     fp, lr, [sp], #0x20
+            ldp     fp, lr, [sp], #0x10
             br      x2
 						;; size=8 bbWeight=1 PerfScore 2.00
-; Total bytes of code: 72
+; Total bytes of code: 60

dotnet-policy-service · 2025-05-25T18:05:50Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2025-05-25T18:06:20Z

src/coreclr/jit/lower.cpp

+            if (arg->OperIs(GT_FIELD_LIST))
            {
-                unsigned int regIndex = 0;
-                for (GenTreeFieldList::Use& use : arg->AsFieldList()->Uses())
-                {
-                    const ABIPassingSegment& segment = abiInfo.Segment(regIndex);
-                    InsertPutArgReg(&use.NodeRef(), segment);
-
-                    regIndex++;
-                }
+                LowerArgFieldList(callArg, arg->AsFieldList());
+                arg = *ppArg;


This is enabled everywhere now since even single-reg args can be structs with multiple fields.

Add support using bitwise operations to reconstruct registers passed into calls from multiple promoted fields. Remove the IR invariant that `FIELD_LIST` args must always map cleanly to registers; instead, any `FIELD_LIST` is allowed for register-only arguments before lowering, and lowering takes care to normalize them into a handled shape. `fgTryMorphStructArg` is changed to take advantage of this by now producing `FIELD_LIST` even when a promoted arg does not match the target ABI. Support in physical promotion will be added in a follow up. Split arguments are not handled and retain the old IR invariant of requiring registers and stack slots to make cleanly from `FIELD_LIST`. win-x64 examples: ```csharp static void Foo(int x) { Use<int?>(x); Use<int?>(5); Use<int?>(null); } ``` ```diff G_M7200_IG02: ;; offset=0x0004 - mov byte ptr [rsp+0x20], 1 - mov dword ptr [rsp+0x24], ecx - mov rcx, qword ptr [rsp+0x20] + mov ecx, ecx + shl rcx, 32 + or rcx, 1 call [Program:Bar(System.Nullable`1[int])] - mov dword ptr [rsp+0x24], 5 - mov rcx, qword ptr [rsp+0x20] + mov rcx, 0x500000001 call [Program:Bar(System.Nullable`1[int])] - mov byte ptr [rsp+0x20], 0 xor ecx, ecx - mov dword ptr [rsp+0x24], ecx - mov rcx, qword ptr [rsp+0x20] - ;; size=55 bbWeight=1 PerfScore 14.25 + ;; size=34 bbWeight=1 PerfScore 7.50 G_M7200_IG03: add rsp, 40 tail.jmp [Program:Bar(System.Nullable`1[int])] ;; size=10 bbWeight=1 PerfScore 2.25 ``` ```csharp static void Foo(int x, float y) { Use((x, y)); } ``` ```diff G_M42652_IG01: ;; offset=0x0000 - push rax - ;; size=1 bbWeight=1 PerfScore 1.00 + ;; size=0 bbWeight=1 PerfScore 0.00 G_M42652_IG02: - mov dword ptr [rsp], ecx - vmovss dword ptr [rsp+0x04], xmm1 - mov rcx, qword ptr [rsp] + vmovd eax, xmm1 + shl rax, 32 + mov ecx, ecx + or rcx, rax ;; size=13 bbWeight=1 PerfScore 3.00 G_M42652_IG03: - add rsp, 8 tail.jmp [Program:Use[System.ValueTuple`2[int,float]](System.ValueTuple`2[int,float])] ``` A win-arm64 example: ```diff G_M33990_IG01: - stp fp, lr, [sp, #-0x20]! + stp fp, lr, [sp, #-0x10]! mov fp, sp - str xzr, [fp, #0x10] // [V03 tmp2] - ;; size=12 bbWeight=1 PerfScore 2.50 + ;; size=8 bbWeight=1 PerfScore 1.50 G_M33990_IG02: cbz x0, G_M33990_IG04 ;; size=4 bbWeight=1 PerfScore 1.00 G_M33990_IG03: - str x0, [fp, #0x10] // [V07 tmp6] - str wzr, [fp, #0x18] // [V08 tmp7] - ldr w0, [x0, #0x08] - str w0, [fp, #0x1C] // [V09 tmp8] + ldr w1, [x0, #0x08] b G_M33990_IG05 - ;; size=20 bbWeight=0.50 PerfScore 3.50 + ;; size=8 bbWeight=0.50 PerfScore 2.00 G_M33990_IG04: - str xzr, [fp, #0x10] // [V07 tmp6] - str xzr, [fp, #0x18] - ;; size=8 bbWeight=0.50 PerfScore 1.00 + mov x0, xzr + mov w1, wzr + ;; size=8 bbWeight=0.50 PerfScore 0.50 G_M33990_IG05: - ldp x0, x1, [fp, #0x10] // [V03 tmp2], [V03 tmp2+0x08] - movz x2, #0xD920 // code for Program:Use[System.Memory`1[int]](System.Memory`1[int]) - movk x2, #0x4590 LSL dotnet#16 + mov w1, w1 + lsl x1, x1, dotnet#32 + movz x2, #0xD950 // code for Program:Use[System.Memory`1[int]](System.Memory`1[int]) + movk x2, #0x4592 LSL dotnet#16 movk x2, #0x7FFE LSL dotnet#32 ldr x2, [x2] - ;; size=20 bbWeight=1 PerfScore 7.50 + ;; size=24 bbWeight=1 PerfScore 6.00 G_M33990_IG06: - ldp fp, lr, [sp], #0x20 + ldp fp, lr, [sp], #0x10 br x2 ;; size=8 bbWeight=1 PerfScore 2.00 -; Total bytes of code: 72 +; Total bytes of code: 60 ```

Wrong for floats...

tannergooding · 2025-05-26T18:30:46Z

It feels like some of the above examples could be optimized slightly, by relying on the fact that 32-bit operations implicitly zero the upper 32-bits of the 64-bit register.

For example, any place where the lower bits aren't coming from register, we can elide a mov:

mov      ecx, ecx    ; This is unnecessary as the shl causes the upper 32-bits to contain the lower 32-bits and lower 32-bits to be zero
shl      rcx, 32
or       rcx, 1

Likewise while the (int, float) example looks optimal, I would expect for (float, int) you could also do 3 instructions instead:

shl      rcx, 32
vmovd    eax, xmm1
or       rcx, rax

I'm then not sure I understand the Arm64 example.

I'd expect for the (int, int) case we would be generating uxtw dst, src (or mov dst, src) followed by orr dst, src1, src2, lsl 32. Similarly the (float, int) example I'd expect we get fmov dst, src followed by orr dst, src1, src2, lsl 32 and for the (int, float) case we'd get fmov dst, src, then uxtw dst, src (or mov dst, src) followed by orr dst, src1, src2, lsl 32 -- If we have a 32-bit constant involved then the uxtw/mov at worst becomes a mov+movk

tannergooding

Changes look good/correct to me.

Might be worth seeing if the better codegen is being missed because we're generally missing an optimization or if there is slightly different IR we should generate

jakobbotsch · 2025-05-26T18:59:55Z

It feels like some of the above examples could be optimized slightly, by relying on the fact that 32-bit operations implicitly zero the upper 32-bits of the 64-bit register.

Right, I also pointed at this case back in #113178. It is not that simple to optimize because it is a necessary type changing cast in the underlying IR. The simplest way to optimize it would probably be an emitter peephole or containing the int -> long cast when used in the x << 32 context.

I'm then not sure I understand the Arm64 example.

I had forgotten to include the corresponding C# code. It is actually conversion of an int[] to a Memory<int> and passing it as an argument afterwards.

tannergooding · 2025-05-26T19:09:49Z

I had forgotten to include the corresponding C# code. It is actually conversion of an int[] to a Memory and passing it as an argument afterwards.

Gotcha. I think we're missing a peephole or containment opportunity for the lsl here then. Nothing we should block on of course, but I think we can remove 1 or 2 of the instructions here and just get orr dst, src1, src2, lsl 32 generated instead

hez2010 · 2025-05-27T13:01:34Z

It seems that we are still spilling the return value before passing it to a use method call:

UseValue(GetValue());

[MethodImpl(MethodImplOptions.NoInlining)]
static int? GetValue()
{
    return 42;
}

[MethodImpl(MethodImplOptions.NoInlining)]
static void UseValue(int? value) { }

Codegen:

G_M27646_IG02:  ;; offset=0x0004
       call     [Program:GetValue():System.Nullable`1[int]]
       mov      qword ptr [rsp+0x20], rax
       mov      rcx, qword ptr [rsp+0x20]
       call     [Program:UseValue(System.Nullable`1[int])]
       nop

I think it can be improved by adding support in physical promotion?

jakobbotsch · 2025-05-27T13:09:40Z

It seems that we are still spilling the return value before passing it to a use method call:

UseValue(GetValue());

[MethodImpl(MethodImplOptions.NoInlining)]
static int? GetValue()
{
    return 42;
}

[MethodImpl(MethodImplOptions.NoInlining)]
static void UseValue(int? value) { }

Codegen:

G_M27646_IG02:  ;; offset=0x0004
       call     [Program:GetValue():System.Nullable`1[int]]
       mov      qword ptr [rsp+0x20], rax
       mov      rcx, qword ptr [rsp+0x20]
       call     [Program:UseValue(System.Nullable`1[int])]
       nop

I think it can be improved by adding support in physical promotion?

There is still no bitwise handling for return values from calls. I may add support for that for the single-reg case in .NET 10, but it's unlikely that the support will come for the multireg case in .NET 10 as that requires a new IR representation (it's the two missing items under ABI handling in #109635).

Even if support for the single-reg case is added in .NET 10 it will likely result in unnecessary bitwise operations in this case. It will require work to remove old promotion before we can get rid of that, I think.

jakobbotsch · 2025-05-27T15:24:50Z

src/coreclr/jit/morph.cpp

+        if (!argNode->TypeIs(TYP_STRUCT) && arg->AbiInfo.HasExactlyOneRegisterSegment())
        {


All independently promoted structs passed in one register are converted to FIELD_LIST above with this change, so this condition is always false now.

(This is referring to deleted code above this line)

jakobbotsch · 2025-05-27T15:28:18Z

src/coreclr/jit/morph.cpp

+//-----------------------------------------------------------------------------
+// FieldsMatchAbi:
+//   Check if the fields of a local map cleanly (in terms of offsets) to the
+//   specified ABI info.
+//
+// Arguments:
+//   varDsc  - promoted local
+//   abiInfo - ABI information
+//
+// Returns:
+//   True if it does. In that case FIELD_LIST usage is allowed for split args
+//   by the backend.
+//
+bool Compiler::FieldsMatchAbi(LclVarDsc* varDsc, const ABIPassingInformation& abiInfo)
+{
+    if (varDsc->lvFieldCnt != abiInfo.CountRegsAndStackSlots())
+    {
+        return false;
+    }
+
+    for (const ABIPassingSegment& seg : abiInfo.Segments())
+    {
+        if (seg.IsPassedInRegister())
+        {
+            unsigned fieldLclNum = lvaGetFieldLocal(varDsc, seg.Offset);
+            if (fieldLclNum == BAD_VAR_NUM)
+            {
+                return false;
+            }
+        }
+        else
+        {
+            for (unsigned offset = 0; offset < seg.Size; offset += TARGET_POINTER_SIZE)
+            {
+                if (lvaGetFieldLocal(varDsc, seg.Offset + offset) == BAD_VAR_NUM)
+                {
+                    return false;
+                }
+            }
+        }
+    }
+
+    return true;
+}


This is only used for args split across registers and stack (arm32 mainly). These args retain the old IR requirements of needing fields to map cleanly to registers and stack slots.

I might clean that up as a separate future PR, but I have a long term ambition to remove special handling of split arguments in the backend entirely by physically splitting the arg in the call node into multiple args instead, as part of lowering. In fact I think multireg args could also be handled this way which would make the backend much more uniform around this.

jakobbotsch · 2025-05-28T09:52:26Z

cc @dotnet/jit-contrib PTAL @EgorBo

Diffs. Overall perfscore and size improvements across the board, with some regressions here and there.

The size improvements on arm64 are generally not as pronounced since the existing pattern uses loads which are quite compact (ldp), and the new pattern is quite large on arm64. For example, a common example diff in the size regressions looks like

-            ldp     x2, x3, [fp, #0x40]	// [V08 tmp4], [V08 tmp4+0x08]
-            ldp     x0, x1, [fp, #0x30]	// [V09 tmp5], [V09 tmp5+0x08]
+            mov     x1, x21
+            mov     w0, w20
+            mov     w2, w19
+            orr     x0, x2, x0,  LSL #32
+            ldp     x2, x3, [fp, #0x28]	// [V08 tmp4], [V08 tmp4+0x08]

We should be able to eliminate at least one of those mov's as discussed above, and perhaps ubfiz/sbfiz can be used in some other cases to improve things even more. Perf-wise I am not that worried in these cases, I would still expect the bitwise version to do better.

One case that is clearly a regression -- sometimes we transform a promoted local into FIELD_LIST(LCL_VAR<long>, LCL_VAR<int>, LCL_VAR<int>) fields in morph, but then still end up with dependent promotion of that local for other reasons (typically because it is stored from a call). In that case it would have been better to pass it as FIELD_LIST(LCL_FLD<long>, LCL_FLD<long>) like before. E.g. a diff in those cases looks like

We could identify and recombine fields in this case during lowering, but I expect to continue removing dependent promotion cases in the future, so this is a point-in-time problem.

There are some throughput regressions. The big ones are in collections with very few MinOpts collections though, so generally it is just around ~0.1% in MinOpts. The detailed TP diff is

Base: 17274781343, Diff: 17290066161, +0.0885%

39109000  : NA       : 60.61% : +0.2264% : private: void __cdecl Lowering::InsertPutArgReg(struct GenTree **, class ABIPassingSegment const &)
795360    : NA       : 1.23%  : +0.0046% : `Compiler::fgTryMorphStructArg'::`39'::<lambda_1>::operator()                                      
-96207    : -5.45%   : 0.15%  : -0.0006% : public: bool __cdecl Compiler::fgTryMorphStructArg(class CallArg *)                                
-795360   : -100.00% : 1.23%  : -0.0046% : `Compiler::fgTryMorphStructArg'::`63'::<lambda_1>::operator()                                      
-23725022 : -40.22%  : 36.77% : -0.1373% : private: void __cdecl Lowering::LowerArg(struct GenTreeCall *, class CallArg *)

so it looks like MSVC just stopped inlining InsertPutArgReg into LowerArg. Maybe native PGO will fix that.

jakobbotsch · 2025-05-28T09:55:32Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2025-05-28T09:55:51Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2025-05-28T12:48:13Z

Failures are #116041, #116060, #110988

EgorBo · 2025-05-28T13:37:38Z

src/coreclr/jit/abi.cpp

+// GetRegisterType:
+//  Return the smallest type larger or equal to Size that most naturally
+//  represents the register this segment is passed in, taking into account the
+//  GC info of the specified layout.


nit: the formatting is a bit off (2 spaces vs 3 spaces for Return value, also, missing arg section)

Let me address that in a follow-up

EgorBo · 2025-05-28T13:47:27Z

src/coreclr/jit/lower.cpp

+        if ((i == numRegs - 1) && !varTypeUsesFloatReg(regType))
+        {
+            // Allow tail end to pass undefined bits into the register
+            regEnd = regStart + REGSIZE_BYTES;


I'm just curious, do we have a guarantee that we won't load the undefined bits as a payload somehow?

Yes, upper bits of registers containing struct values are undefined in the managed ABI. So this is ok. (This is just ensuring the handling matches what we had before; without this there was a bunch of regressions).

I think the actual source that creates these loads is morph:

runtime/src/coreclr/jit/morph.cpp

Lines 2442 to 2449 in 7e41ae6

#ifdef TARGET_ARM64

if ((offset > 0) && argNode->OperIsLocalRead())

{

// For arm64 it's beneficial to consider all tails to

// be TYP_I_IMPL to allow more ldp's.

type = TYP_I_IMPL;

}

#endif

I'm not sure it's worth it -- this means we sometimes can generate 2x 8byte loads => ldp instead of one 8 byte + one < 8 byte load, so the code is slightly smaller. But then maybe that may result in a stall? Probably worth to see if we can come up with an example and then maybe remove it if we can.

EgorBo

That's pretty cool!

github-actions bot added the area-CodeGen-coreclr label May 25, 2025

dotnet-policy-service bot assigned jakobbotsch May 25, 2025

jakobbotsch commented May 25, 2025

View reviewed changes

jakobbotsch force-pushed the bitwise-insert-call-arguments branch from 5748cbf to 0aa3197 Compare May 25, 2025 18:09

Revert genParamStackType change

3b2b47b

Wrong for floats...

tannergooding approved these changes May 26, 2025

View reviewed changes

jakobbotsch mentioned this pull request May 27, 2025

JIT struct work planned for .NET 10 #109635

Open

17 tasks

jakobbotsch added 2 commits May 27, 2025 16:10

Fix some regressions

ea33fd6

Only for last register

bd51930

jakobbotsch mentioned this pull request May 27, 2025

JIT: Fix some logic in field list handling in lowering #116013

Closed

jakobbotsch commented May 27, 2025

View reviewed changes

Handle primitives passed in multiple registers

f55ba17

jakobbotsch marked this pull request as ready for review May 28, 2025 09:33

jakobbotsch requested a review from EgorBo May 28, 2025 09:52

build-analysis bot mentioned this pull request May 28, 2025

Test failure: Microsoft.Extensions.Hosting.Internal.HostTests.HostLifetimeOnStartedCanBeCancelled #110988

Open

EgorBo reviewed May 28, 2025

View reviewed changes

EgorBo approved these changes May 28, 2025

View reviewed changes

jakobbotsch merged commit 0c88424 into dotnet:main May 28, 2025
123 of 134 checks passed

jakobbotsch deleted the bitwise-insert-call-arguments branch May 28, 2025 14:43

This was referenced May 28, 2025

JIT: Some bitwise ops are not folded by lowering when reassociation is required #116077

Open

JIT: Support bitwise field extractions from parameter registers #112740

Draft

jakobbotsch mentioned this pull request Jun 10, 2025

JIT: Wrong result forwarding argument for tailcall on linux-x64 #116466

Closed

		if (!argNode->TypeIs(TYP_STRUCT) && arg->AbiInfo.HasExactlyOneRegisterSegment())
		{

	#ifdef TARGET_ARM64
	if ((offset > 0) && argNode->OperIsLocalRead())
	{
	// For arm64 it's beneficial to consider all tails to
	// be TYP_I_IMPL to allow more ldp's.
	type = TYP_I_IMPL;
	}
	#endif

JIT: Support bitwise field insertions for call arguments #115977

JIT: Support bitwise field insertions for call arguments #115977

Uh oh!

Conversation

jakobbotsch commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service bot commented May 25, 2025

Uh oh!

jakobbotsch May 25, 2025

Choose a reason for hiding this comment

Uh oh!

tannergooding commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tannergooding left a comment

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented May 26, 2025

Uh oh!

tannergooding commented May 26, 2025

Uh oh!

hez2010 commented May 27, 2025

Uh oh!

jakobbotsch commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakobbotsch May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakobbotsch commented May 28, 2025

Uh oh!

azure-pipelines bot commented May 28, 2025

Uh oh!

jakobbotsch commented May 28, 2025

Uh oh!

EgorBo May 28, 2025

Choose a reason for hiding this comment

Uh oh!

jakobbotsch May 28, 2025

Choose a reason for hiding this comment

Uh oh!

EgorBo May 28, 2025

Choose a reason for hiding this comment

Uh oh!

jakobbotsch May 28, 2025

Choose a reason for hiding this comment

Uh oh!

EgorBo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jakobbotsch commented May 25, 2025 •

edited

Loading

tannergooding commented May 26, 2025 •

edited

Loading

jakobbotsch commented May 27, 2025 •

edited

Loading

jakobbotsch May 27, 2025 •

edited

Loading

jakobbotsch May 27, 2025 •

edited

Loading

jakobbotsch commented May 28, 2025 •

edited

Loading