JIT ARM32: Force tailcall nullchecks with LR by jakobbotsch · Pull Request #68107 · dotnet/runtime

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

jakobbotsch · 2022-04-16T09:58:56Z

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix#66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost · 2022-04-16T09:59:04Z

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

Issue Details

For interface tail calls we need to allocate registers for both the
target and a null-check. The register that can be used for the target is
highly constrained: it essentially only go into r12 as the arg registers
may be busy and that is the only volatile register left that will not be
overridden by the epilog. This leaves
just LR left for the null check, and LSRA does not seem to handle the
low amount of freedom too well (these are all allocated at the same
location, which might have something to do with it).

To help LSRA just force the null-check to happen with LR for fast
tailcalls, which is going to be killed going into the epilog anyway.

Fix #66563

cc @dotnet/jit-contrib @kunalspathak, this is the alternative fix

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

kunalspathak

LGTM

For interface tail calls we need to allocate registers for both the target and a null-check. The register that can be used for the target is highly constrained: it essentially only go into r12 as the arg registers may be busy and that is the only volatile register left that will not be overridden by the epilog. This leaves just `LR` left for the null check, and LSRA does not seem to handle the low amount of freedom too well (these are all allocated at the same location, which might have something to do with it). To help LSRA just force the null-check to happen with LR for fast tailcalls, which is going to be killed going into the epilog anyway. Fixdotnet#66563

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 16, 2022

ghost assigned jakobbotsch Apr 16, 2022

jakobbotsch mentioned this pull request Apr 16, 2022
ARM32: stop allocating a register for null checks on instance calls #68100
Closed

kunalspathak reviewed Apr 18, 2022
View reviewed changes

Comment threadsrc/coreclr/jit/lsraarmarch.cpp

kunalspathak approved these changes Apr 18, 2022
View reviewed changes

kunalspathak merged commit 928bd97 into dotnet:mainApr 18, 2022

ghost locked as resolved and limited conversation to collaborators May 18, 2022

Uh oh!

Conversation

jakobbotsch commented Apr 16, 2022

Uh oh!

ghost commented Apr 16, 2022

Uh oh!

Uh oh!

kunalspathak left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 16, 2022

Uh oh!

ghost commented Apr 16, 2022

Uh oh!

Uh oh!

kunalspathak left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 16, 2022

Uh oh!

ghost commented Apr 16, 2022

Uh oh!

Uh oh!

kunalspathak left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 16, 2022

Uh oh!

ghost commented Apr 16, 2022

Uh oh!

Uh oh!

kunalspathak left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 16, 2022

Uh oh!

ghost commented Apr 16, 2022

Uh oh!

Uh oh!

kunalspathak left a comment