Fix contained LCL_VAR_ADDR in RMW.

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib

[sandreenko]

Call emitIns_S_I (stack immediate) to generate instruction like:

Generating: N008 ( 1, 1) [000005] -c---------- t5 = CNS_INT long 123 REG NA $200
/--* t4 long
+--* t5 long
Generating: N010 ( 8, 9) [000006] -c--G------- t6 = * ADD long REG NA <l:$241, c:$240>
Generating: N012 ( 3, 4) [000000] Uc-----N---- t0 = LCL_VAR_ADDR byref V00 arg0 NA REG NA
/--* t0 byref
+--* t6 long
Generating: N014 (???,???) [000012] -A--G------- * STOREIND long REG NA
IN0001: 000009 add qword ptr [rsp+08H], 123

Questions that I had:

1. should not it be fixed in emitHandleMemOp?
   no, because emitHandleMemOp already has an instruction descriptor and it is wrong for this situation because it expects A meaning dereference Address in a register. We could change the fmt inside like we do for:
   

   runtime/src/coreclr/jit/emitxarch.cpp

   Lines 2931 to 2932 in 5265305

   	// fmt - the instruction format to use. This must be one of the ARD, AWR, or ARW formats. If necessary (such as for
   	// GT_CLS_VAR_ADDR), this function will map it to the correct format.

   
   but it would require a copy-paste of emitIns_S_I into this function.
   Another argument is that we already treat LCL_VAR_ADDR/LCL_FLD_ADDR differently, to show such cases I have changed OperIs(GT_LCL_VAR_ADDR, GT_LCL_FLD_ADDR) to OperIsLocalAddr().

A better long-term solution would be to rewrite emitHandleMemOp to create id but we don't have time for it now.

2. Do we need to call genUpdateLife for the local?
   It appears not to be necessary because the variable liveness does not change there so we can skip it.
   However, we can do this, as you see 000000 is marked VAR_USEASG so call to genUpdateLife(storeInd) will give us the correct result, UpdateLifeVar just won't do anything with it. I could still add these calls if I hear an opinion that it will be less confusing.

3. Have I caught all places that need this fix?
   I checked all calls to emitHandleMemOp and found 1 more place that was fixed in this PR, others already have it or don't work with contained LCL_VAR_ADDR.

Fixes#41073 and #49880.

No spmi-diffs.

[sandreenko]

PTAL @BruceForstall @dotnet/jit-contrib