Merge branch 'main' into issue-20234

Author: deeprobin

.config/dotnet-tools.json

@@ -15,7 +15,7 @@
       ]
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "1.0.0-prerelease.22270.1",
+      "version": "1.0.0-prerelease.22305.1",
       "commands": [
         "xharness"
       ]

docs/design/coreclr/jit/first-class-structs.md

@@ -70,11 +70,6 @@ Current Representation of Struct Values
 
 These struct-typed nodes are created by the importer, but transformed in morph, and so are not
 encountered by most phases of the JIT:
-* `GT_INDEX`: This is transformed to a `GT_IND`
-  * Currently, the IND is marked with `GTF_IND_ARR_INDEX` and the node pointer of the `GT_IND` acts as a key
-    into the array info map.
-  * Proposed: This should be transformed into a `GT_OBJ` when it represents a struct type, and then the
-    class handle would no longer need to be obtained from the array info map.
 * `GT_FIELD`: This is transformed to a `GT_LCL_VAR` by the `Compiler::fgMarkAddressExposedLocals()` phase
   if it's a promoted struct field, or to a `GT_LCL_FLD` or GT_IND` by `fgMorphField()`.
   * Proposed: A non-promoted struct typed field should be transformed into a `GT_OBJ`, so that consistently all struct
@@ -90,9 +85,7 @@ encountered by most phases of the JIT:
 ### Struct “objects” as lvalues
 
 * The lhs of a struct assignment is a block or local node:
-  * `GT_OBJ` nodes represent the “shape” info via a struct handle, along with the GC info
-    (location and type of GC references within the struct).
-    * These are currently used only to represent struct values that contain GC references (although see below).
+  * `GT_OBJ` nodes represent struct types with a handle, and store a pointer to the `ClassLayout` object.
   * `GT_BLK` nodes represent struct types with no GC references, or opaque blocks of fixed size.
     * These have no struct handle, resulting in some pessimization or even incorrect
       code when the appropriate struct handle can't be determined.
@@ -101,12 +94,12 @@ encountered by most phases of the JIT:
       [#21705](https://github.com/dotnet/coreclr/pull/21705) they are no longer large nodes.
   * `GT_STORE_OBJ` and `GT_STORE_BLK` have the same structure as `GT_OBJ` and `GT_BLK`, respectively
     * `Data()` is op2
-  * `GT_DYN_BLK` and `GT_STORE_DYN_BLK` (GenTreeDynBlk extends GenTreeBlk)
+  * `GT_STORE_DYN_BLK` (GenTreeStoreDynBlk extends GenTreeBlk)
     * Additional child `gtDynamicSize`
-    * Note that these aren't really struct types; they represent dynamically sized blocks
+    * Note that these aren't really struct stores; they represent dynamically sized blocks
       of arbitrary data.
-  * For `GT_LCL_FLD` nodes, we don't retain shape information, except indirectly via the `FieldSeqNode`.
-  * For `GT_LCL_VAR` nodes, the`ClassLayout` is obtained from the `LclVarDsc`.
+  * For `GT_LCL_FLD` nodes, we store a pointer to `ClassLayout` in the node.
+  * For `GT_LCL_VAR` nodes, the `ClassLayout` is obtained from the `LclVarDsc`.
 
 ### Struct “objects” as rvalues
 
@@ -131,10 +124,6 @@ After morph, a struct-typed value on the RHS of assignment is one of:
 * `GT_CALL`
 * `GT_LCL_VAR`
 * `GT_LCL_FLD`
-  * Note: With `compDoOldStructRetyping()`, a GT_LCL_FLD` with a primitive type of the same size as the struct
-    is used to represent a reference to the full struct when it is passed in a register.
-    This forces the struct to live on the stack, and makes it more difficult to optimize these struct values,
-    which is why this mechanism is being phased out.
 * `GT_SIMD`
 * `GT_OBJ` nodes can also be used as rvalues when they are call arguments
   * Proposed: `GT_OBJ` nodes can be used in any context where a struct rvalue or lvalue might occur,
@@ -173,8 +162,7 @@ There are three main phases in the JIT that make changes to the representation o
         registers. The necessary transformations for correct code generation would be
         made in `Lowering`.
 
-    * With `compDoOldStructRetyping()`, if it is passed in a single register, it is morphed into a
-     `GT_LCL_FLD` node of the appropriate primitive type.
+    * If it is passed in a single register, it is morphed into a `GT_LCL_FLD` node of the appropriate primitive type.
       * This may involve making a copy, if the size cannot be safely loaded.
       * Proposed: This would remain a `GT_OBJ` and would be appropriately transformed in `Lowering`,
         e.g. using `GT_BITCAST`.
@@ -310,22 +298,13 @@ This would be enabled first by [Defer ABI-specific transformations to Lowering](
   for block copies. See [\#21711 Improve init/copy block codegen](https://github.com/dotnet/coreclr/pull/21711).
 
 * This also includes cleanup of the block morphing methods such that block nodes needn't be visited multiple
-  times, such as `fgMorphBlkToInd` (may be simply unneeded), `fgMorphBlkNode` and `fgMorphBlkOperand`.
+  times, such as `fgMorphBlkNode` and `fgMorphBlkOperand`.
   These methods were introduced to preserve old behavior, but should be simplified.
 
-* Somewhat related is the handling of struct-typed array elements. Currently, after the `GT_INDEX` is transformed
-  into a `GT_IND`, that node must be retained as the key into the `ArrayInfoMap`. For structs, this is then
-  wrapped in `OBJ(ADDR(...))`. We should be able to change the IND to OBJ and avoid wrapping, and should also be
-  able to remove the class handle from the array info map and instead used the one provided by the `GT_OBJ`.
-
 ### Miscellaneous Cleanup
 
 These are all marked with `TODO-1stClassStructs` or `TODO-Cleanup` in the last case:
 
-* The handling of `DYN_BLK` is unnecessarily complicated to duplicate previous behavior (i.e. to enable previous
-  refactorings to be zero-diff). These nodes are infrequent so the special handling should just be eliminated
-  (e.g. see `GenTree::GetChild()`).
-
 * The checking at the end of `gtNewTempAssign()` should be simplified.
 
 * When we create a struct assignment, we use `impAssignStruct()`. This code will, in some cases, create

docs/design/specs/Ecma-335-Augments.md

@@ -16,6 +16,7 @@ This is a list of additions and edits to be made in ECMA-335 specifications. It
 - [Ref field support](#ref-fields)
 - [Rules for IL rewriters](#rules-for-il-rewriters)
 - [Checked user-defined operators](#checked-user-defined-operators)
+- [Atomic reads and writes](#atomic-reads-and-writes)
 
 ## Signatures
 
@@ -1013,3 +1014,9 @@ Section "I.10.3.3 Conversion operators" of ECMA-335 adds *op_CheckedExplicit* as
 implementing checked explicit conversion operator.
 
 A checked user-defined operator is expected to throw an exception when the result of an operation is too large to represent in the destination type. What does it mean to be too large actually depends on the nature of the destination type. Typically the exception thrown is a System.OverflowException.
+
+## Atomic reads and writes
+
+Section "I.12.6.6 Atomic reads and writes" adds clarification that the atomicity guarantees apply to built-in primitive value types and pointers only.
+
+A conforming CLI shall guarantee that read and write access of *built-in primitive value types and pointers* to properly aligned memory locations no larger than the native word size (the size of type native int) is atomic (see §I.12.6.2) when all the write accesses to a location are the same size.