JIT: Fix profiler enter callback init reg trash logic by jakobbotsch · Pull Request #100637 · dotnet/runtime

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

jakobbotsch · 2024-04-04T13:06:25Z

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases:

Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback
SysV x64 thought that the enter callback trashed the parameter registers, but it does not

This generally did not cause issues because genFnPrologCalleeRegArgs is unnecessarily conservative around whether or not it trashes initReg, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

Fixes an issue I noticed by inspection over in #100572

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

dotnet-policy-service · 2024-04-04T13:06:58Z

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

jakobbotsch · 2024-04-04T14:58:11Z

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

azure-pipelines · 2024-04-04T14:58:30Z

Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch · 2024-04-04T19:14:23Z

cc @dotnet/jit-contrib PTAL @BruceForstall

BruceForstall · 2024-04-04T19:25:48Z

No diffs -- so no test coverage?

jakobbotsch · 2024-04-04T19:32:13Z

No diffs -- so no test coverage?

We have test coverage in stress due to STRESS_PROFILER_CALLBACKS. I hit the problem over in #100572. There it wasn't a problem in the baseline because genFnPrologCalleeRegArgs mistakenly was marking the initReg as clobbered (even though it didn't actually end up using it for anything).

During prolog generation we sometimes generate code to call the profiler enter callback. This may trash the "initReg" that we expect to keep zeroed during the prolog. The logic to check if the initReg was being trashed was wrong in a couple of cases: - Most backends did not take into account that the logic also trashes the registers used for arguments to the enter callback - SysV x64 thought that the enter callback trashed the parameter registers, but it does not This generally did not cause issues because `genFnPrologCalleeRegArgs` is unnecessarily conservative around whether or not it trashes `initReg`, and it comes after the profiler callback in the prolog. However, with the rewrite of the homing function that is not going to be the case anymore.

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

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

dotnet-policy-serviceBot assigned jakobbotsch Apr 4, 2024

Fix Windows build
7feab54

jakobbotsch marked this pull request as ready for review April 4, 2024 19:14

jakobbotsch requested a review from BruceForstall April 4, 2024 19:14

BruceForstall approved these changes Apr 4, 2024
View reviewed changes

jakobbotsch merged commit 96d5a66 into dotnet:mainApr 4, 2024

jakobbotsch deleted the profiler-trashed branch April 4, 2024 19:33

github-actionsBot locked and limited conversation to collaborators May 5, 2024

Uh oh!

Conversation

jakobbotsch commented Apr 4, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

azure-pipelinesBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

BruceForstall commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 4, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

azure-pipelinesBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

BruceForstall commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 4, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

azure-pipelinesBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

BruceForstall commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

jakobbotsch commented Apr 4, 2024

Uh oh!

dotnet-policy-serviceBot commented Apr 4, 2024

Uh oh!

jakobbotsch commented Apr 4, 2024

Uh oh!