JIT: extend copy prop to local fields #74384

AndyAyersMS · 2022-08-22T21:09:03Z

Allow copy prop to update GT_LCL_FLD nodes.

Update local assertion gen for block opts to use the pre-morph tree
to generate copy or zero assertions, since the semantics of the post-morph
tree are often obscured by the copy/zero expansions.

Allow copy prop to update GT_LCL_FLD nodes. Update local assertion gen for block opts to use the pre-morph tree to generate copy or zero assertions, since the semantics of the post-morph tree are often obscured by the copy/zero expansions.

ghost · 2022-08-22T21:09:17Z

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

Issue Details

Allow copy prop to update GT_LCL_FLD nodes.

Update local assertion gen for block opts to use the pre-morph tree
to generate copy or zero assertions, since the semantics of the post-morph
tree are often obscured by the copy/zero expansions.

Author:	AndyAyersMS
Assignees:	AndyAyersMS
Labels:	`area-CodeGen-coreclr`
Milestone:	-

AndyAyersMS · 2022-08-22T21:10:56Z

This is an alternate take on #73719.

Lots of good looking improvements. A few big regressions that I haven't investigated yet. Also some opportunities for follow up, eg if we have V06 == 0 and V04 == V06 and a lcl field use off of V04 we should be creating a zero, it seems.

AndyAyersMS · 2022-08-22T21:14:47Z

cc @dotnet/jit-contrib

SingleAccretion · 2022-08-22T21:19:15Z

src/coreclr/jit/morph.cpp

+    if ((oldTree != nullptr) && oldTree->OperIsBlkOp())
+    {
+        optAssertionGen(oldTree);
+    }


I don't think we can really use oldTree here... It should really be a DEBUGARG, the contract is that it can be reshapen/destroyed/reused in arbitrary ways.

All we really need to know is the identity of the local(s) involved, so I suppose we can find some other way to convey this information.

Would calling this from somewhere inside fgMorphCopy/InitBlock not work? We are already doing this "manual" assertion generation for field assigns there.

It needs to survive fgKillDependentAssertions somehow.

Do it after the killing?

Hmm, I am missing something here.

By the time we get to fgMorphTreeDone, for a decomposed store, we'll have a COMMA chain, which will not be recognized as a store (and thus will not kill the assertions).

What I was thinking as "the kill point" is this code:

runtime/src/coreclr/jit/morphblock.cpp

Lines 255 to 259 in b06ab8c

// Kill everything about m_dstLclNum (and its field locals)

if (m_comp->optLocalAssertionProp && (m_comp->optAssertionCount > 0))

{

m_comp->fgKillDependentAssertions(m_dstLclNum DEBUGARG(m_asg));

}

Where we still have the original assign.

Edit: this does still leave the wrinkle of killing the assertions of non-decomposed stores, but that can, presumably, be dealt with by moving out all of struct copy assertion generation from fgMorphTreeDone.

That might work. It scatters the gen/kill logic around a bit more, but I suppose we've already crossed that bridge.

I certainly want to avoid having to inspect the expanded tree to figure out what to kill/preserve/gen.

Strange that we kill assertions for init block but not for copy block.

Ah, I guess we inherit that.

Tried a variant of what's discussed above: putting the assertion gen over in MorphInitBlockHelper::Morph after the dest is prepared but before the copy is morphed.

This misses some cases where we turn the copy into a single assignment to its field.

;;; current PR ("hacky revival of old tree") Morphing BB01 of 'SocketConnection:DisposeAsync():ValueTask:this' fgMorphTree BB01, STMT00008 (before) [000037] IA--------- * ASG struct (init) [000034] D------N--- +--* LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 +--* ref V04.m_task (offs=0x00) -> V09 tmp6 [000036] ----------- \--* CNS_INT int 0 Notify VM instruction set (SSE2) must be supported. MorphInitBlock: MorphBlock for dst tree, before: [000034] D----+-N--- * LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 * ref V04.m_task (offs=0x00) -> V09 tmp6 MorphBlock after: [000034] D----+-N--- * LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 * ref V04.m_task (offs=0x00) -> V09 tmp6 PrepareDst for [000034] have found a local var V04. using field by field initialization. GenTreeNode creates assertion: [000047] -A--------- * ASG ref In BB01 New Local Constant Assertion: V09 == null, index = #01 MorphInitBlock (after): [000047] -A---+----- * ASG ref [000045] D------N--- +--* LCL_VAR ref V09 tmp6 [000046] ----------- \--* CNS_INT ref null The assignment [000047] using V09 removes: Constant Assertion: V09 == null GenTreeNode creates assertion: [000047] -A---+----- * ASG ref In BB01 New Local Constant Assertion: V09 == null, index = #01 GenTreeNode creates assertion: [000037] IA--------- * ASG struct (init) In BB01 New Local Constant Assertion: V04 == ZeroObj, index = #02

compared to

;;; alternate version (revive during morph block init) Morphing BB01 of 'SocketConnection:DisposeAsync():ValueTask:this' fgMorphTree BB01, STMT00008 (before) [000037] IA--------- * ASG struct (init) [000034] D------N--- +--* LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 +--* ref V04.m_task (offs=0x00) -> V09 tmp6 [000036] ----------- \--* CNS_INT int 0 Notify VM instruction set (SSE2) must be supported. MorphInitBlock: MorphBlock for dst tree, before: [000034] D----+-N--- * LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 * ref V04.m_task (offs=0x00) -> V09 tmp6 MorphBlock after: [000034] D----+-N--- * LCL_VAR struct<System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder, 8>(P) V04 tmp1 * ref V04.m_task (offs=0x00) -> V09 tmp6 PrepareDst for [000034] have found a local var V04. GenTreeNode creates assertion: [000037] IA--------- * ASG struct (init) In BB01 New Local Constant Assertion: V04 == ZeroObj, index = #01 using field by field initialization. GenTreeNode creates assertion: [000047] -A--------- * ASG ref In BB01 New Local Constant Assertion: V09 == null, index = #02 MorphInitBlock (after): [000047] -A---+----- * ASG ref [000045] D------N--- +--* LCL_VAR ref V09 tmp6 [000046] ----------- \--* CNS_INT ref null The assignment [000047] using V09 removes: Constant Assertion: V09 == null The assignment [000047] using V04 removes: Constant Assertion: V04 == ZeroObj GenTreeNode creates assertion: [000047] -A---+----- * ASG ref In BB01 New Local Constant Assertion: V09 == null, index = #01

I could either try and recognize those cases in fgMorphTreeDone and avoid the kill, or update optAssertionGen to understand that assertions about an entire field of a struct also apply to the struct, so that the assertion gets killed but then gets revived again.

SingleAccretion · 2022-08-22T21:25:27Z

src/coreclr/jit/assertionprop.cpp

+    //
+    if (tree->OperIs(GT_LCL_FLD))
+    {
+        if (copyVarDsc->IsEnregisterableLcl() || copyVarDsc->lvPromotedStruct())


Nit: one almost never wants to call lvPromotedStruct() instead of just checking lvPromoted. If we start having non-struct promoted variables in the future, we'll want this behavior for them as well.

Orthogonally, this is a bit conservative. If we already know copyVarDsc is not going to be enregistered, it should be ok to propagate it, so lvaGetPromotionType(copyVarDsc) == PROMOTION_TYPE_INDEPENDENT should in theory be a better check.

I saw quite a few more regressions with promoted structs. Will have to look more closely.

I saw quite a few more regressions with promoted structs

I suppose that addresses the PROMOTION_TYPE_INDEPENDENT idea. Guessing these could have been from SSA-based optimization not working as well (since promoted structs are excluded from all of them).

AndyAyersMS · 2022-08-22T21:36:30Z

Also wondering if it's worth checking for transitive copies. For scalar types it matters less -- one hopes LSRA, say can clean up all the residual copies. But for structs it could be a bigger deal.

Edit: I suppose this should just fall out, if we have say a chain of struct assigns and then a partial use:

y = x;
z = y;
   = lclFld(z)

we should produce

y = x;
z = x;
   = lclFld(z);

and then

y = x;
z = x;
   = lclFld(x);

But perhaps we could see cases where we think forwarding y is a bad idea but forwarding x is ok.

AndyAyersMS · 2022-08-23T00:14:10Z

SPMI: despite the overall code size reduction, throughput increases, which is a little puzzling.

AndyAyersMS · 2022-08-24T00:07:19Z

Interestingly we'll CSE LCL_FLD with zero VNs but will not constant prop zeros into LCL_FLDs. So will look into enabling constant prop I guess.

Still not settled on how to actually plumb through the info.

SingleAccretion · 2022-08-24T10:02:29Z

src/coreclr/jit/assertionprop.cpp

+    if (varTypeIsStruct(tree))
+    {
+        tree->BashToZeroConst(TYP_INT);
+    }
+    else
+    {
+        tree->BashToZeroConst(tree->TypeGet());
+    }


Isn't the !varTypeIsStruct branch dead code?

(We have an assert to that effect at the top)

SingleAccretion · 2022-08-24T10:03:48Z

src/coreclr/jit/assertionprop.cpp

+    // TODO: create proper simd zero constant
+    //
+    if (varTypeIsSIMD(tree))
+    {
+        return false;
+    }


We should skip creating ZeroObj assertions for varTypeIsSIMD. ZeroObj is really meant for TYP_STRUCT only.

SingleAccretion · 2022-08-24T10:04:27Z

src/coreclr/jit/assertionprop.cpp

+                case GT_OBJ:
+                case GT_BLK:
+                {
+                    GenTree* const addr = op2->AsIndir()->Addr();
+
+                    if (addr->OperIs(GT_ADDR))
+                    {
+                        GenTree* const base = addr->AsOp()->gtOp1;
+
+                        if (base->OperIs(GT_LCL_VAR))
+                        {
+                            // layout compat?
+                            op2 = base;
+                            goto IS_COPY;
+                        }
+                    }
+
+                    goto DONE_ASSERTION;
+                }
+


Is this still necessary after #71584?

(If it is, it should have a TODO-ADDR: delete once <...> comment)

Will check once I pick up those changes.

There are still some cases where it helps -- about 700 all told across SPMI

;;; String:Replace(ushort,ushort):String:this (MethodHash=5aa7fa78) #16249 in ASP.NET fgMorphTree BB15, STMT00064 (before) [000326] -A--------- * ASG simd32 (copy) [000324] D------N--- +--* LCL_VAR simd32<System.Numerics.Vector`1[System.UInt16]> V29 tmp12 [000208] n---------- \--* OBJ simd32<System.Numerics.Vector`1[System.UInt16]> [000207] ----------- \--* ADDR byref [000203] -------N--- \--* LCL_VAR simd32<System.Numerics.Vector`1[System.UInt16]> V14 loc11 ;; (with above) GenTreeNode creates assertion: [000326] -A--------- * ASG simd32 (copy) In BB15 New Local Copy Assertion: V29 == V14, index = #01 ... Assertion prop in BB15: Copy Assertion: V29 == V14, index = #01 [000320] ----------- * LCL_VAR simd32<System.Numerics.Vector`1[System.UInt16]> V14 loc11 ;; (without above) no assertion, no copy prop

SIMD types, as one would suspect...

So the comment should be TODO-ADDR: delete once local morph folds SIMD-typed indirections. and we definitely need to check for layout compatibility.

SingleAccretion · 2022-08-24T10:08:35Z

src/coreclr/jit/morph.cpp

-    if (tree->OperIsConst())
-    {
-        goto DONE;
+        assert("ERROR: Did not morph this node!");


Suggested change

assert("ERROR: Did not morph this node!");

assert(!"ERROR: Did not morph this node!");

Is it intentional that we no longer check for double morphing?

Ah, thanks. That checking depended on old tree so I'd have to pass something like that down.

Seems like an odd contract though.

Still producing SIMD ZEROOBJ but no longer looking for them.

AndyAyersMS · 2022-08-26T15:26:01Z

@dotnet/jit-contrib think this is getting close.

I want to spend some more time looking at regressions since some of them are sizeable. So far they fall into a few camps:

early assertion/prop gen/kill for block copies/inits will sometimes lose assertions if those expanded into a single promoted field copy. I have a variant where I rerun assertion gen late but it was not a consistent win.
some cases where value numbering's memory model is unable to reason about structs with known values; I think there is possibly something off with in the model (73 (192.11 % of base) : 44847.dasm - N.Repro1:RunTest():int from coreclr_tests.pmi.windows.x64.checked
cases where in-body zeroing is more compact that prolog zeroing
cases where LSRA make different choices
struct copyprop may lead to different copy expansions. These variations do not seem at times to be all that well motivated. At any rate, if it turns out that all the appearances of a struct are now per-field copy destinations, those dests get marked as GTF_VAR_USEASG and keep the struct and all writes alive even if there are no actual (explicit) reads. This doesn't happen if the struct is written wholesale. This explains quite a few of the bigger asp.net regressions. For example, in 72 ( 5.14% of base) : 92282.dasm - <ReadBufferAsync>d__72:MoveNext():this from asp.net we see:

;; before

       mov      rdx, gword ptr [rbp-40H]
       ; gcrRegs +[rdx]
       mov      ecx, dword ptr [rbp-38H]
       movsx    rax, word  ptr [rbp-34H]
       mov      gword ptr [rbp-60H], rdx
       mov      dword ptr [rbp-58H], ecx
       mov      word  ptr [rbp-54H], ax
       mov      byte  ptr [rbp-52H], 0
						;; size=77 bbWeight=4    PerfScore 97.00
G_M43996_IG07:        ; , nogc, extend
       vmovdqu  xmm0, xmmword ptr [rbp-60H]
       vmovdqu  xmmword ptr [rbp-30H], xmm0

						;; size=10 bbWeight=4    PerfScore 16.00
G_M43996_IG08:        ; , isz, extend
       mov      rdi, gword ptr [rbp-30H]

;; after

       mov      rdx, gword ptr [rbp-40H]
       ; gcrRegs +[rdx]
       mov      ecx, dword ptr [rbp-38H]
       movsx    rax, word  ptr [rbp-34H]
       mov      gword ptr [rbp-70H], rdx
       mov      dword ptr [rbp-68H], ecx
       mov      word  ptr [rbp-64H], ax
       mov      byte  ptr [rbp-62H], 0

       mov      gword ptr [rbp-50H], rdx   ;; dead copy
       mov      dword ptr [rbp-48H], ecx
       mov      word  ptr [rbp-44H], ax
       mov      byte  ptr [rbp-42H], 0

       mov      gword ptr [rbp-30H], rdx
       mov      dword ptr [rbp-28H], ecx
       mov      word  ptr [rbp-24H], ax
       mov      byte  ptr [rbp-22H], 0
       mov      rdi, gword ptr [rbp-30H]

(plus another identical case later)

I suspect that second copy is perhaps partially dead but perhaps kept alive by the same issue with GTF_VAR_USEASG. Though one would hope that last read could just be rdx so maybe more is going on.

I wonder how hard it would be to model this in liveness.

AndyAyersMS · 2022-08-29T15:54:19Z

@kunalspathak can you review?

kunalspathak · 2022-08-29T16:11:57Z

@kunalspathak can you review?

Sure, will do it later today.

kunalspathak

Added some questions specifically around optAssertionPropDone. I didn't quite understand it. Can you please explain the design around it?

kunalspathak · 2022-08-29T23:42:07Z

src/coreclr/jit/morph.cpp

+                // Block ops handle assertion kill/gen specially.
+                // See PrepareDst and PropagateAssertions
+                //
+                if (optAssertionPropDone != nullptr)


So here we say that we are doing struct1 = struct2 and is candidate for copy prop?

No, all that happens over in optAssertionProp_LclVar and the new optAssertionProp_LclFld. before the tree is morphed.

This check is asking whether or not we've already killed and generated assertions from the post-morph tree.

src/coreclr/jit/compiler.h

src/coreclr/jit/assertionprop.cpp

AndyAyersMS · 2022-08-30T04:56:11Z

Added some questions specifically around optAssertionPropDone. I didn't quite understand it. Can you please explain the design around it?

Global morph runs over each basic block in order, and in each block, over each statement in order, and in each statement, each node in order. During global morph we enable "local" assertion prop; at the start of each block, we clear out the assertion table.

Before morphing each node, we try and apply the currently active assertions to the tree. Then when we're done morphing the node, we kill off any assertions that are no longer true and try and generate new assertions. This is more or less standard forward data flow on assertions. The set of assertion we track is pretty limited: var = constant; var is nonnull; var = other var.

The first part of this PR is to enable assertion prop into LCL_FLD uses. It was inspired by code I saw in #66776 where we copied a struct and then just read one field of the copy.

The approach outlines above works pretty well for most nodes, but does not work well for struct inits and struct copies, because the code in assertion prop can't always recognize the zeroings and copes once they've been expanded. In particular when a struct copy gets expanded as field by field copy, the sequence of stores to the LCL_FLDs of the dest would kill any assertion about the dest.

The second part of this PR tries to improve things generating assertions for struct inits and copies after the source and dest are processed but before the assign node itself is processed. (note we were already doing the kills early on). That way we know what assertions to gen.

We need to remember that we've done this "early assertion gen / kill" for these particular trees so we don't do kills again later on in fgMorphTreeDone. That's what optAssertionPropDone is for. We can't make this part of ambient morph state because it applies just to the root node of one particular tree, not to an entire tree.

kunalspathak · 2022-08-30T21:18:20Z

We need to remember that we've done this "early assertion gen / kill" for these particular trees so we don't do kills again later on in fgMorphDone.

That makes sense. Thank you for the explaination.

AndyAyersMS · 2022-09-01T16:50:40Z

Regressions:

[Perf] ubuntu 18.04/arm64 : Regression on 8/30/2022 9:25:07 PM perf-autofiling-issues#8230
[Perf] Linux/x64: 41 Regressions on 8/24/2022 2:39:26 AM perf-autofiling-issues#8254 (some)
[Perf] Windows/x64: 8 Regressions on 8/30/2022 9:25:07 PM perf-autofiling-issues#8391
[Perf] Linux/x64: 4 Regressions on 8/30/2022 9:25:07 PM perf-autofiling-issues#8315
[Perf] Windows/x64: 2 Regressions on 8/30/2022 9:25:07 PM perf-autofiling-issues#8310

Improvements

[Perf] ubuntu 18.04/arm64 : Improvement on 8/30/2022 9:25:07 PM perf-autofiling-issues#8241
[Perf] ubuntu 18.04/arm64 : Improvement on 8/29/2022 4:29:28 PM perf-autofiling-issues#8240
[Perf] Windows 10.0.19041/arm64 : Improvement on 8/30/2022 9:25:07 PM perf-autofiling-issues#8237
[Perf] Windows 10.0.25094/arm64 : Improvement on 8/30/2022 9:25:07 PM perf-autofiling-issues#8213
[Perf] ubuntu 20.04/arm64 : Improvement on 8/30/2022 9:25:07 PM perf-autofiling-issues#8218
[Perf] ubuntu 18.04/x64 : Improvement on 8/30/2022 9:25:07 PM perf-autofiling-issues#8264
[Perf] Windows/x64: 23 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8402
[Perf] Windows/x64: 22 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8323
[Perf] Linux/x64: 13 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8325
[Perf] Windows/arm64: 2 Improvements on 8/30/2022 6:17:03 PM perf-autofiling-issues#8422
[Perf] Windows/arm64: 2 Improvements on 9/3/2022 6:04:34 PM perf-autofiling-issues#8423
[Perf] Linux/arm64: 22 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8425
[Perf] Linux/arm64: 10 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8442
[Perf] Windows/arm64: 23 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8428
[Perf] Windows/x86: 28 Improvements on 8/30/2022 9:25:07 PM perf-autofiling-issues#8302

AndyAyersMS · 2022-09-08T01:14:44Z

There are two tests that show substantial regressions across os/isa combinations:

(ubuntu x64)

A few other tests show small regressions.

In dotnet#74384 I modified morph to generate assertions before a block op was morphed, but after the source and dest were morphed. This misses generating some assertions that arise once the expanded form is known. We now re-run assertion gen on the expanded tree, when we do an `OneAsgBlock` expansion. Other cases my also prove profitable. Closes dotnet#75229.

In #74384 I modified morph to generate assertions before a block op was morphed, but after the source and dest were morphed. This misses generating some assertions that arise once the expanded form is known. We now re-run assertion gen on the expanded tree, when we do an `OneAsgBlock` expansion. Other cases my also prove profitable. Closes #75229.

JIT: extend copy prop to local fields

f1d8333

Allow copy prop to update GT_LCL_FLD nodes. Update local assertion gen for block opts to use the pre-morph tree to generate copy or zero assertions, since the semantics of the post-morph tree are often obscured by the copy/zero expansions.

ghost assigned AndyAyersMS Aug 22, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Aug 22, 2022

JulieLeeMSFT added this to the 8.0.0 milestone Aug 22, 2022

SingleAccretion reviewed Aug 22, 2022

View reviewed changes

AndyAyersMS added 3 commits August 23, 2022 19:45

fix x86 issue

aafa84b

alternate version where we gen during morph block

bd69556

plumb flag through to decide what to do in fgMorphTreeDone

0360119

SingleAccretion reviewed Aug 24, 2022

View reviewed changes

AndyAyersMS added 4 commits August 24, 2022 21:45

First bit of feedback.

a5ea0eb

Still producing SIMD ZEROOBJ but no longer looking for them.

restore GTF_DEBUG_NODE_MORPHED checks

813f22e

Merge remote-tracking branch 'upstream/main' into CopyPropLclFld

acfdc15

add comment and layout check to optCreateAssertion

752e701

AndyAyersMS mentioned this pull request Aug 26, 2022

JIT: extend forward sub to local fields #73719

Closed

This was referenced Aug 26, 2022

JIT: morph late canonicalization of assign foils local assertion prop #12098

Closed

[JIT] Assertion Prop Issues and Ideas #74671

Open

kunalspathak reviewed Aug 29, 2022

View reviewed changes

kunalspathak approved these changes Aug 30, 2022

View reviewed changes

AndyAyersMS merged commit 50b426b into dotnet:main Aug 30, 2022

AndyAyersMS mentioned this pull request Aug 31, 2022

System.Collections.Sort<BigStruct>.LinqQuery has regressed on all configs except Windows 64 bit #66776

Closed

This was referenced Sep 1, 2022

Test failure JIT\\Performance\\CodeQuality\\Roslyn\\CscBench\\CscBench.cmd #74900

Closed

[Perf] Linux/x64: 41 Regressions on 8/24/2022 2:39:26 AM dotnet/perf-autofiling-issues#8254

Closed

AndyAyersMS mentioned this pull request Sep 8, 2022

JIT: perf regression from improved local struct copy prop #75229

Closed

AndyAyersMS mentioned this pull request Sep 9, 2022

JIT: propagate some block assertions after expansion #75321

Merged

jakobbotsch mentioned this pull request Sep 9, 2022

JIT: Bad codegen on win-x86 #75249

Closed

ghost locked as resolved and limited conversation to collaborators Oct 14, 2022

	// Kill everything about m_dstLclNum (and its field locals)
	if (m_comp->optLocalAssertionProp && (m_comp->optAssertionCount > 0))
	{
	m_comp->fgKillDependentAssertions(m_dstLclNum DEBUGARG(m_asg));
	}

	assert("ERROR: Did not morph this node!");
	assert(!"ERROR: Did not morph this node!");

JIT: extend copy prop to local fields #74384

JIT: extend copy prop to local fields #74384

Uh oh!

Conversation

AndyAyersMS commented Aug 22, 2022

Uh oh!

ghost commented Aug 22, 2022

Uh oh!

AndyAyersMS commented Aug 22, 2022

Uh oh!

AndyAyersMS commented Aug 22, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SingleAccretion Aug 22, 2022 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SingleAccretion Aug 22, 2022 • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS commented Aug 22, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndyAyersMS commented Aug 23, 2022

Uh oh!

AndyAyersMS commented Aug 24, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS commented Aug 26, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndyAyersMS commented Aug 29, 2022

Uh oh!

kunalspathak commented Aug 29, 2022

Uh oh!

kunalspathak left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

SingleAccretion Aug 22, 2022 •

edited

Loading

SingleAccretion Aug 22, 2022 •

edited

Loading

AndyAyersMS commented Aug 22, 2022 •

edited

Loading

AndyAyersMS commented Aug 26, 2022 •

edited

Loading

AndyAyersMS commented Aug 30, 2022 •

edited

Loading

AndyAyersMS commented Sep 1, 2022 •

edited

Loading