JIT: Fix physical promotion creating overlapping local uses by jakobbotsch · Pull Request #91058 · dotnet/runtime

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

jakobbotsch · 2023-08-24T13:33:52Z

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between two local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix#91056

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses. The example looks like the following. Physical promotion would be faced with a tree like ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 ``` When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation: ``` ▌ CALL void Program:Foo(Program+S,Program+S) ├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) └──▌ COMMA struct ├──▌ STORE_LCL_FLD int V01 loc0 [+0] │ └──▌ LCL_VAR int V02 tmp0 └──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use) ``` This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation. The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement. Fixdotnet#91056

ghost · 2023-08-24T13:34:05Z

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

Issue Details

Physical promotion could in some cases create uses overlapping illegally with defs when faced with seemingly last uses of structs. This is a result of a mismatch between our model for liveness and the actual model of local uses in the backend. In the actual model, the uses of LCL_VARs occur at the user, which means that it is possible for there to be no place at which to insert IR between to local uses.

The example looks like the following. Physical promotion would be faced with a tree like

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0

When V01 was fully promoted, both of these are logically last uses since all state of V01 is stored in promoted field locals. Because of that we would make the following transformation:

▌ CALL void Program:Foo(Program+S,Program+S)
├──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)
└──▌ COMMA struct
├──▌ STORE_LCL_FLD int V01 loc0 [+0]
│ └──▌ LCL_VAR int V02 tmp0
└──▌ LCL_VAR struct<Program+S, 4> V01 loc0 (last use)

This creates an illegally overlapping use and def; additionally, it is correct only in a world where the store actually would happen between the two uses. It is also moderately dangerous to mark both of these as last uses given the implicit byref transformation.

The fix is to avoid marking a struct use as a last use if we see more struct uses in the same statement.

Fix #91056

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

jakobbotsch · 2023-08-24T16:17:36Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

Diffs. Just a single one in a test case.

jakobbotsch · 2023-08-24T19:09:30Z

/backport to release/8.0

github-actions · 2023-08-24T19:09:44Z

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/5967909534

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

ghost assigned jakobbotsch Aug 24, 2023

jakobbotsch marked this pull request as ready for review August 24, 2023 16:15

jakobbotsch requested a review from AndyAyersMS August 24, 2023 16:17

AndyAyersMS approved these changes Aug 24, 2023
View reviewed changes

jakobbotsch merged commit 20a7de9 into dotnet:mainAug 24, 2023

jakobbotsch deleted the fix-91056 branch August 24, 2023 19:09

github-actionsBot mentioned this pull request Aug 24, 2023
[release/8.0] JIT: Fix physical promotion creating overlapping local uses #91088
Merged

ghost locked as resolved and limited conversation to collaborators Sep 24, 2023