JIT: Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint by amanasifkhalid · Pull Request #99827 · dotnet/runtime

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid · 2024-03-15T17:00:33Z

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

dotnet-policy-service · 2024-03-15T17:00:56Z

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

amanasifkhalid · 2024-03-15T20:09:10Z

Diffs

AndyAyersMS · 2024-03-16T17:32:34Z

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

amanasifkhalid · 2024-03-18T18:06:36Z

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

AndyAyersMS · 2024-03-18T18:27:55Z

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

jakobbotsch · 2024-03-19T09:39:33Z

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

jakobbotsch

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

amanasifkhalid added 2 commits March 15, 2024 12:28

Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint
9ca5fc6

Check for no-fallthrough types
6677ca5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 15, 2024

dotnet-policy-serviceBot assigned amanasifkhalid Mar 15, 2024

jakobbotsch approved these changes Mar 19, 2024
View reviewed changes

amanasifkhalid merged commit 43a9236 into dotnet:mainMar 19, 2024

amanasifkhalid deleted the loopCompactionInsert branch March 19, 2024 14:36

github-actionsBot locked and limited conversation to collaborators Apr 19, 2024

Uh oh!

Conversation

amanasifkhalid commented Mar 15, 2024

Uh oh!

dotnet-policy-serviceBot commented Mar 15, 2024

Uh oh!

amanasifkhalid commented Mar 15, 2024

Uh oh!

AndyAyersMS commented Mar 16, 2024

Uh oh!

amanasifkhalid commented Mar 18, 2024

Uh oh!

AndyAyersMS commented Mar 18, 2024

Uh oh!

jakobbotsch commented Mar 19, 2024

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

amanasifkhalid commented Mar 15, 2024

Uh oh!

dotnet-policy-serviceBot commented Mar 15, 2024

Uh oh!

amanasifkhalid commented Mar 15, 2024

Uh oh!

AndyAyersMS commented Mar 16, 2024

Uh oh!

amanasifkhalid commented Mar 18, 2024

Uh oh!

AndyAyersMS commented Mar 18, 2024

Uh oh!

jakobbotsch commented Mar 19, 2024

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

amanasifkhalid commented Mar 15, 2024

Uh oh!

dotnet-policy-serviceBot commented Mar 15, 2024

Uh oh!

amanasifkhalid commented Mar 15, 2024

Uh oh!

AndyAyersMS commented Mar 16, 2024

Uh oh!

amanasifkhalid commented Mar 18, 2024

Uh oh!

AndyAyersMS commented Mar 18, 2024

Uh oh!

jakobbotsch commented Mar 19, 2024

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!