Don't use VN when it's already stale #97943

EgorBo · 2024-02-04T13:47:11Z

Runtime lookup expansion could use VNs when it's no longer legal.
gcIsWriteBarrierCandidate could use VNs even in codegen phase.

VN_BASED_DEAD_STORE_REMOVAL is the last phase where we still can rely on VNs.

ghost · 2024-02-04T13:47:20Z

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

Issue Details

Runtime lookup expansion could use VNs when it's no longer legal.
gcIsWriteBarrierCandidate could use VNs even in codegen phase.

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

EgorBo · 2024-02-04T15:07:48Z

A regression example:

Details

***** BB01 [0000]
STMT00001 ( 0x008[E-] ... 0x00E )
N008 ( 26, 32) [000007] hACXGO--R--                         *  STOREIND  ref    $183
N007 (  4, 11) [000090] -A---------                         +--*  COMMA     long   $c1
N005 (  3, 10) [000088] DA---------                         |  +--*  STORE_LCL_VAR long   V10 cse2         d:1 $VN.Void
N004 (  3, 10) [000006] H----------                         |  |  \--*  CNS_INT(h) long   0x26609801f60 static Fseq[<unknown field>] $c1
N006 (  1,  1) [000089] -----------                         |  \--*  LCL_VAR   long   V10 cse2         u:1 $c1
N003 ( 18, 18) [000005] --CXG------                         \--*  CALL help ref    CORINFO_HELP_NEWARR_1_VC $182
N001 (  3, 10) [000004] H---------- arg0 in rcx                +--*  CNS_INT(h) long   0x7ffd7df983b8 class $c0
N002 (  1,  1) [000003] ----------- arg1 in rdx                \--*  CNS_INT   long   1 $100

***** BB01 [0000]
STMT00002 ( 0x013[E-] ... 0x01A )
N021 ( 22, 24) [000013] nA-XGO-----                         *  STORE_BLK struct<RefWrapper, 8> (init) <l:$18c, c:$18b>
N019 ( 14, 18) [000045] -A-XGO-----                         +--*  COMMA     byref  <l:$303, c:$302>
N006 (  4,  4) [000032] DA--G------                         |  +--*  STORE_LCL_VAR ref    V05 tmp3         d:2 $VN.Void
N005 (  4,  4) [000085] -A--G------                         |  |  \--*  COMMA     ref    <l:$200, c:$1c2>
N003 (  3,  3) [000083] DA--G------                         |  |     +--*  STORE_LCL_VAR ref    V09 cse1         d:1 $VN.Void
N002 (  3,  2) [000009] n---G------                         |  |     |  \--*  IND       ref    <l:$200, c:$1c2>
N001 (  1,  1) [000091] -----------                         |  |     |     \--*  LCL_VAR   long   V10 cse2         u:1 $c1
N004 (  1,  1) [000084] -----------                         |  |     \--*  LCL_VAR   ref    V09 cse1         u:1 <l:$200, c:$1c2>
N018 ( 10, 14) [000080] -A-X-O-----                         |  \--*  COMMA     byref  <l:$303, c:$302>
N016 (  9, 13) [000078] DA-X-O-----                         |     +--*  STORE_LCL_VAR byref  V08 cse0         d:1 $VN.Void
N015 (  9, 13) [000044] ---X-O-----                         |     |  \--*  COMMA     byref  <l:$303, c:$302>
N010 (  8, 11) [000037] ---X-O-----                         |     |     +--*  BOUNDS_CHECK_Rng void   <l:$18c, c:$18b>
N007 (  1,  1) [000010] -----------                         |     |     |  +--*  CNS_INT   int    0 $41
N009 (  3,  3) [000036] ---X-------                         |     |     |  \--*  ARR_LENGTH int    <l:$42, c:$2c0>
N008 (  1,  1) [000033] -----------                         |     |     |     \--*  LCL_VAR   ref    V05 tmp3         u:2 <l:$200, c:$1c2>
N014 (  1,  2) [000043] -----O-----                         |     |     \--*  ARR_ADDR  byref RefWrapper[] $340
N013 (  1,  2) [000042] -------N---                         |     |        \--*  ADD       byref  <l:$300, c:$301>
N011 (  1,  1) [000034] -----------                         |     |           +--*  LCL_VAR   ref    V05 tmp3         u:2 (last use) <l:$200, c:$1c2>
N012 (  1,  1) [000041] -----------                         |     |           \--*  CNS_INT   long   16 $101
N017 (  1,  1) [000079] -----------                         |     \--*  LCL_VAR   byref  V08 cse0         u:1 <l:$303, c:$302>
N020 (  1,  1) [000011] -----------                         \--*  CNS_INT   int    0 $41

***** BB01 [0000]
STMT00004 ( 0x01F[E-] ... ??? )
N006 (  9,  9) [000061] DA--GO-----                         *  STORE_LCL_VAR ref    V04 tmp2         d:2 <l:$18c, c:$192>
N005 (  5,  6) [000060] nA--GO-----                         \--*  IND       ref    <l:$194, c:$193>
N004 (  2,  4) [000059] -A--GO-----                            \--*  COMMA     byref  <l:$303, c:$305>
N002 (  1,  3) [000046] DA--G------                               +--*  STORE_LCL_VAR ref    V06 tmp4         d:2 $VN.Void
N001 (  1,  1) [000086] -----------                               |  \--*  LCL_VAR   ref    V09 cse1         u:1 <l:$200, c:$1c2>
N003 (  1,  1) [000081] -----------                               \--*  LCL_VAR   byref  V08 cse0         u:1 $340

***** BB01 [0000]
STMT00005 ( 0x025[E-] ... 0x02C )
N006 (  9,  9) [000077] nA--GO-----                         *  STOREIND  ref    <l:$18c, c:$19a>
N004 (  2,  4) [000075] -A--GO-----                         +--*  COMMA     byref  <l:$303, c:$307>
N002 (  1,  3) [000062] DA--G------                         |  +--*  STORE_LCL_VAR ref    V07 tmp5         d:2 $VN.Void
N001 (  1,  1) [000087] -----------                         |  |  \--*  LCL_VAR   ref    V09 cse1         u:1 <l:$200, c:$1c2>
N003 (  1,  1) [000082] -----------                         |  \--*  LCL_VAR   byref  V08 cse0         u:1 $340
N005 (  3,  2) [000076] -----------                         \--*  LCL_VAR   ref    V04 tmp2         u:2 (last use) <l:$VN.Null, c:$1c6>

***** BB01 [0000]
STMT00006 ( 0x031[E-] ... 0x031 )
N001 (  0,  0) [000023] -----------                         *  RETURN    void   $VN.Void

It looks like gcIsWriteBarrierCandidate was relying on Liberal VN for VNNull and it was kind of too optimistic? See [000076] tree

EgorBo · 2024-02-04T15:43:59Z

src/coreclr/jit/helperexpansion.cpp

-    GenTree**   callUse      = nullptr;
-    Statement*  newFirstStmt = nullptr;
-    block                    = fgSplitBlockBeforeTree(block, stmt, call, &newFirstStmt, &callUse);
-    assert(prevBb != nullptr && block != nullptr);


Unrelated change, just a clean up since SplitAtTreeAndReplaceItWithLocal does exactly that.

EgorBo · 2024-02-04T17:07:40Z

PTAL @jakobbotsch @AndyAyersMS cc @dotnet/jit-contrib Diffs 12 methods regressed in Tests because of #97943 (comment)

AndyAyersMS

LGTM.

Looks like the gcinfo use of VNs goes way back.

EgorBo · 2024-02-04T20:59:01Z

CI Failure is #97049

jakobbotsch · 2024-02-05T09:40:03Z

src/coreclr/jit/gcinfo.cpp

@@ -240,8 +240,8 @@ GCInfo::WriteBarrierForm GCInfo::gcIsWriteBarrierCandidate(GenTreeStoreInd* stor
    }

    // Ignore any assignments of NULL.
-    GenTree* const data = store->Data()->gtSkipReloadOrCopy();
-    if ((data->GetVN(VNK_Liberal) == ValueNumStore::VNForNull()) || data->IsIntegralConst(0))
+    GenTree* const data = store->Data()->gtSkipReloadOrCopy()->gtEffectiveVal();


Why this change? GT_COMMA should not exist at this point, and if it did it is questionable to not skip reloads inside it (would cause issues during codegen).

Agree, completely unnecessary, will remove as part of some other PR

jakobbotsch · 2024-02-05T09:47:26Z

src/coreclr/jit/gentree.h

@@ -4101,7 +4101,7 @@ enum GenTreeCallFlags : unsigned int
    GTF_CALL_M_GUARDED_DEVIRT_CHAIN    = 0x00080000, // this call is a candidate for chained guarded devirtualization
    GTF_CALL_M_ALLOC_SIDE_EFFECTS      = 0x00100000, // this is a call to an allocator with side effects
    GTF_CALL_M_SUPPRESS_GC_TRANSITION  = 0x00200000, // suppress the GC transition (i.e. during a pinvoke) but a separate GC safe point is required.
-    GTF_CALL_M_EXP_RUNTIME_LOOKUP      = 0x00400000, // this call needs to be transformed into CFG for the dynamic dictionary expansion feature.
+    GTF_CALL_M_EXP_RUNTIME_LOOKUP      = 0x00400000, // [DEBUG only] this call needs to be transformed into CFG for the dynamic dictionary expansion feature.


If this is debug only can you please move it to GenTreeCallDebugFlags?

It was sort of unrelated to this PR, but good idea! One less bit occupied.

Don't use VN when it's already stale

3d7be2c

dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Feb 4, 2024

ghost assigned EgorBo Feb 4, 2024

EgorBo added 2 commits February 4, 2024 15:07

fix formatting

780bc62

Clean up

c58e347

EgorBo mentioned this pull request Feb 4, 2024

JIT: CSE of an address computation can result in a write barrier change #97534

Closed

EgorBo commented Feb 4, 2024

View reviewed changes

EgorBo marked this pull request as ready for review February 4, 2024 16:07

EgorBo requested review from AndyAyersMS and jakobbotsch February 4, 2024 17:07

This was referenced Feb 4, 2024

Tracking issue for CI build timeouts #76454

Closed

Tests crashing in CI with no dump: exit code 137 means SIGKILL Killed #97049

Closed

AndyAyersMS approved these changes Feb 4, 2024

View reviewed changes

EgorBo merged commit 8aa6afc into dotnet:main Feb 4, 2024
127 of 129 checks passed

EgorBo deleted the assertprop-wb-fix-2 branch February 4, 2024 20:59

jakobbotsch reviewed Feb 5, 2024

View reviewed changes

DrewScoggins mentioned this pull request Feb 6, 2024

[Perf] Windows/x64: 1 Regression on 2/4/2024 8:59:19 PM dotnet/perf-autofiling-issues#28672

Open

github-actions bot locked and limited conversation to collaborators Mar 7, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't use VN when it's already stale #97943

Don't use VN when it's already stale #97943

EgorBo commented Feb 4, 2024 •

edited

Loading

ghost commented Feb 4, 2024

EgorBo commented Feb 4, 2024 •

edited

Loading

EgorBo Feb 4, 2024

EgorBo commented Feb 4, 2024 •

edited

Loading

AndyAyersMS left a comment

EgorBo commented Feb 4, 2024

jakobbotsch Feb 5, 2024

EgorBo Feb 5, 2024

jakobbotsch Feb 5, 2024

EgorBo Feb 5, 2024

Don't use VN when it's already stale #97943

Don't use VN when it's already stale #97943

Conversation

EgorBo commented Feb 4, 2024 • edited Loading

ghost commented Feb 4, 2024

EgorBo commented Feb 4, 2024 • edited Loading

EgorBo Feb 4, 2024

Choose a reason for hiding this comment

EgorBo commented Feb 4, 2024 • edited Loading

AndyAyersMS left a comment

Choose a reason for hiding this comment

EgorBo commented Feb 4, 2024

jakobbotsch Feb 5, 2024

Choose a reason for hiding this comment

EgorBo Feb 5, 2024

Choose a reason for hiding this comment

jakobbotsch Feb 5, 2024

Choose a reason for hiding this comment

EgorBo Feb 5, 2024

Choose a reason for hiding this comment

EgorBo commented Feb 4, 2024 •

edited

Loading

EgorBo commented Feb 4, 2024 •

edited

Loading

EgorBo commented Feb 4, 2024 •

edited

Loading