[mono][interp] Fix type of args when inlining method by BrzVlad · Pull Request #102570 · dotnet/runtime

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad · 2024-05-22T15:51:43Z

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern:

	condbr	BB0
newobj	Derived // push var0 of type Derived
br	BB1
BB0:
newobj	Base	// push var1 of type Base
// here we will end up inserting a `mov var1 -> var0`
BB1:
// top of stack will be seen as being var0
call

Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack.

In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

Fixes#102046

dotnet-policy-service · 2024-05-22T15:52:10Z

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

BrzVlad · 2024-05-22T15:53:36Z

Simple repro for this issue:

using System;
public class Base {
public virtual void Method ()
{
Console.WriteLine ("Base");
}
}
public sealed class Derived : Base {
public override void Method ()
{
Console.WriteLine ("Derived");
}
}
public class Program {
public static bool true_var = true;
public static void CallMethod (Base obj)
{
obj.Method ();
} public static void Main (string[] args)
{
// Bug manifests only in optimized code, so we need to tier up method
for (int i = 0; i < 1001; i++) {
// Should call Base, interp incorrectly devirts to Derived
CallMethod (true_var ? new Base () : new Derived ()); }
}
}

lewing

Should a regression test be added somewhere?

srxqds · 2024-05-23T02:07:15Z

need backport .net8.0?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

srxqds · 2024-05-27T01:56:53Z

need backport .net8.0?

?

The vars allocated from pushing values on the execution stack might not reflect exactly the actual type of the var. Consider this pattern: condbr BB0 newobj Derived // push var0 of type Derived br BB1 BB0: newobj Base // push var1 of type Base // here we will end up inserting a `mov var1 -> var0` BB1: // top of stack will be seen as being var0 call Because we first reach BB1 with the stack contents of var0, BB1 will end up accessing top of the stack as var0. However the type of var0 at this point is not Derived, since it can also be a Base object. We currently don't update the type of var0, but just update the type information of the top of stack entry when entering BB1. When inlining, after this commit, we use the type information from the stack, rather than the type of the var present on the stack. In the future we might want to consider updating the type of var0 or creating a new var entirely with the correct type for consistency.

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

BrzVlad requested a review from kotlarmilos as a code owner May 22, 2024 15:51

ghost added the area-Codegen-Interpreter-mono label May 22, 2024

dotnet-policy-serviceBot assigned BrzVlad May 22, 2024

lewing approved these changes May 22, 2024
View reviewed changes

build-analysisBot mentioned this pull request May 22, 2024
Abort on mono in SwiftErrorHandling #102478
Closed

kotlarmilos approved these changes May 23, 2024
View reviewed changes

BrzVlad force-pushed the fix-interp-devirt-inline branch from 9696467 to 9ed71dcCompare May 23, 2024 09:41

lewing mentioned this pull request May 24, 2024
MT-System.Threading.Tests timeout #102664
Closed

lewing merged commit fc5b6e7 into dotnet:mainMay 24, 2024

BrzVlad mentioned this pull request May 29, 2024
[release/8.0] [mono][interp] Fix type of args when inlining method #102801
Merged

This was referenced May 29, 2024
[Perf] Linux/x64: 4 Regressions on 5/24/2024 5:41:08 PM dotnet/perf-autofiling-issues#35199
Open
[wasm][perf] Tracking #96444
Open

github-actionsBot locked and limited conversation to collaborators Jun 27, 2024

Uh oh!

Conversation

BrzVlad commented May 22, 2024• edited by akoeplinger Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 22, 2024

Uh oh!

BrzVlad commented May 22, 2024

Uh oh!

lewing left a comment

Choose a reason for hiding this comment

Uh oh!

srxqds commented May 23, 2024

Uh oh!

srxqds commented May 27, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

BrzVlad commented May 22, 2024• edited by akoeplinger Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 22, 2024

Uh oh!

BrzVlad commented May 22, 2024

Uh oh!

lewing left a comment

Choose a reason for hiding this comment

Uh oh!

srxqds commented May 23, 2024

Uh oh!

srxqds commented May 27, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

BrzVlad commented May 22, 2024• edited by akoeplinger Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 22, 2024

Uh oh!

BrzVlad commented May 22, 2024

Uh oh!

lewing left a comment

Choose a reason for hiding this comment

Uh oh!

srxqds commented May 23, 2024

Uh oh!

srxqds commented May 27, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

BrzVlad commented May 22, 2024• edited by akoeplinger Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 22, 2024

Uh oh!

BrzVlad commented May 22, 2024

BrzVlad commented May 22, 2024•
edited by akoeplinger
Loading

BrzVlad commented May 22, 2024•
edited by akoeplinger
Loading

BrzVlad commented May 22, 2024•
edited by akoeplinger
Loading

BrzVlad commented May 22, 2024•
edited by akoeplinger
Loading

BrzVlad commented May 22, 2024•
edited by akoeplinger
Loading