JIT: Assertion failed '!"Write to unaliased local overlaps outstanding read"' during 'Rationalize IR' #91056
Assignees
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone
Comments
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsCreated based on an example generated by Antigen. using System.Runtime.CompilerServices;
public class Program
{
public static void Main(string[] args)
{
S s = default;
if (args.Length > 0)
{
s.A = 1234;
}
Foo(0, 0, s, s);
}
[MethodImpl(MethodImplOptions.NoInlining)]
private static void Use(int x)
{
}
[MethodImpl(MethodImplOptions.NoInlining)]
private static void Foo(int a, int b, S s1, S s2)
{
}
public struct S
{
public int A;
}
}Run with $env:DOTNET_JitNoCse=1
$env:DOTNET_JitStressModeNames="STRESS_NO_OLD_PROMOTION STRESS_PHYSICAL_PROMOTION_COST"
$env:DOTNET_TieredCompilation=0
|
jakobbotsch
removed
the
untriaged
jakobbotsch
added a commit
to jakobbotsch/runtime
that referenced
this issue
Aug 24, 2023
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 dotnet#91056
ghost
added
the
in-pr
jakobbotsch
added a commit
that referenced
this issue
Aug 24, 2023
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
ghost
removed
the
in-pr
github-actions bot
pushed a commit
that referenced
this issue
Aug 24, 2023
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
carlossanlop
pushed a commit
that referenced
this issue
Aug 25, 2023
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 Co-authored-by: Jakob Botsch Nielsen <[email protected]>
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Created based on an example generated by Antigen.
Run on win-x86 with
The text was updated successfully, but these errors were encountered: