JIT: Clean up inliner substitution by jakobbotsch · Pull Request #77176 · dotnet/runtime

jakobbotsch · 2022-10-18T17:14:27Z

Stop using GenTree::ReplaceWith
GenTreeRetExpr now directly contains its substitution members, which is a tree either from the inline candidate, a local (due to spill temps) or the call itself (due to inliner failure). In the former case, it also contains the BasicBlock the child tree comes from to ensure that its flags can be propagated once and for all during substitution.
Make various members strongly typed, e.g. GenTreeRetExpr::gtInlineCandidate is now a GenTreeCall*, InlineCandidateInfo::retExpr is now a GenTreeRetExpr*. This is possible since we are no longer using GenTree::ReplaceWith.

* Stop using GenTree::ReplaceWith * GenTreeRetExpr now directly contains its substitution members, which is a tree either from the inline candidate, a local (due to spill temps) or the call itself (due to inliner failure). In the former case, it also contains the BasicBlock the child tree comes from to ensure that its flags can be propagated once and for all during substitution. * Make various members strongly typed, e.g. GenTreeRetExpr::gtInlineCandidate is now a GenTreeCall*, InlineCandidateInfo::retExpr is now a GenTreeRetExpr*. This is possible since we are no longer using GenTree::ReplaceWith.

ghost · 2022-10-18T17:14:45Z

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

Issue Details

Stop using GenTree::ReplaceWith
GenTreeRetExpr now directly contains its substitution members, which is a tree either from the inline candidate, a local (due to spill temps) or the call itself (due to inliner failure). In the former case, it also contains the BasicBlock the child tree comes from to ensure that its flags can be propagated once and for all during substitution.
Make various members strongly typed, e.g. GenTreeRetExpr::gtInlineCandidate is now a GenTreeCall*, InlineCandidateInfo::retExpr is now a GenTreeRetExpr*. This is possible since we are no longer using GenTree::ReplaceWith.

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

jakobbotsch · 2022-10-18T22:19:29Z

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

azure-pipelines · 2022-10-18T22:19:49Z

Azure Pipelines successfully started running 2 pipeline(s).

When we fail to inline, the substitution will be the call itself, so we should propagate flags from the basic block containing the call. In particular this can be a problem with RET_EXPR chains.

jakobbotsch · 2022-10-19T12:41:38Z

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

azure-pipelines · 2022-10-19T12:41:55Z

Azure Pipelines successfully started running 2 pipeline(s).

AndyAyersMS · 2022-10-19T17:11:36Z

Getting the block flags right has been a persistent source of trouble; see eg #37335, #37840, #38243 and probably a few more.

jakobbotsch · 2022-10-19T17:23:50Z

Getting the block flags right has been a persistent source of trouble; see eg #37335, #37840, #38243 and probably a few more.

Indeed, and I'm pretty sure the current way we propagate does not really make logical sense (see TODOs I have added in the source in this PR). I am hoping we are going to make some inliner changes in this release that we can remove those TODOs as part of.

At least this PR accomplishes centralizing all the substitution logic (well, except for GDV) into UpdateInlineReturnExpressionPlaceHolder. Hopefully this is the end of the wrong flag propagation, but I suppose we'll see...

jakobbotsch · 2022-10-19T17:37:03Z

The problem seems simple enough -- whenever we replace a GT_RET_EXPR node with an arbitrary tree, we potentially need to propagate flags from the basic block that the arbitrary tree comes from. But the previous behavior using GenTree::ReplaceWith makes it very difficult to reason about the arbitrary trees and where they are coming from once you start replacing GT_RET_EXPR nodes and the inline candidates with other GT_RET_EXPR nodes. This PR was initially just a clean up to try to simplify the convoluted replacement logic, but turned out to fix the issue too.

jakobbotsch · 2022-10-19T19:52:18Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS @EgorBo

Small number of diffs where nested inlining propagates flags in slightly different ways.

AndyAyersMS

Consider fixing the "prev BB" and BBF_SPLIT_GAINED issues as separate isolated PRs (both from this PR and from each other by a few days), so we can better assess the impact of these via the lab data.

jakobbotsch · 2022-10-20T08:17:19Z

/azp run Fuzzlyn

azure-pipelines · 2022-10-20T08:17:37Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2022-10-20T09:28:03Z

The failures look like #76880 and known from build analysis.

Consider fixing the "prev BB" and BBF_SPLIT_GAINED issues as separate isolated PRs (both from this PR and from each other by a few days), so we can better assess the impact of these via the lab data.

Makes sense.

jakobbotsch · 2022-10-21T11:34:24Z

I cannot reproduce the Fuzzlyn failures on the head of my PR. That probably means they are recent regressions in main.

jakobbotsch · 2022-10-21T17:53:07Z

I'm not able to reproduce it on main either. I have seen these kind of intermittent failures before, so I don't think it's related to this PR. Not sure how we can track these down, I will need to think about if I can record more information from Fuzzlyn.

The failures looked known as mentioned above so will merge.

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

ghost assigned jakobbotsch Oct 18, 2022

jakobbotsch added 2 commits October 18, 2022 19:18

Nit
177fe72

Fix build
82b6655

build-analysisBot mentioned this pull request Oct 19, 2022
Tracking issue for CI build timeouts #76454
Closed

jakobbotsch added 3 commits October 19, 2022 11:48

Propagate BB flags properly on inline failures
37086f7
When we fail to inline, the substitution will be the call itself, so we should propagate flags from the basic block containing the call. In particular this can be a problem with RET_EXPR chains.

Fix dumping, retain odd previous behavior, fix GDV substitution
802ac66

More comments
0177368

build-analysisBot mentioned this pull request Oct 19, 2022
Assertion failed: (*card_word)==0 in DynamicGenerics tests #76801
Closed

jakobbotsch marked this pull request as ready for review October 19, 2022 19:52

jakobbotsch requested review from AndyAyersMS and EgorBo October 19, 2022 19:52

build-analysisBot mentioned this pull request Oct 19, 2022
Nuget restore error caused by 503s dotnet/arcade#11239
Closed
2 tasks

AndyAyersMS approved these changes Oct 20, 2022
View reviewed changes

jakobbotsch merged commit c34ccb1 into dotnet:mainOct 21, 2022

jakobbotsch deleted the fix-75827 branch October 21, 2022 17:53

ghost locked as resolved and limited conversation to collaborators Nov 20, 2022

Uh oh!

Conversation

jakobbotsch commented Oct 18, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Oct 18, 2022

Uh oh!

jakobbotsch commented Oct 18, 2022

Uh oh!

azure-pipelinesBot commented Oct 18, 2022

Uh oh!

jakobbotsch commented Oct 19, 2022

Uh oh!

azure-pipelinesBot commented Oct 19, 2022

Uh oh!

AndyAyersMS commented Oct 19, 2022

Uh oh!

jakobbotsch commented Oct 19, 2022

Uh oh!

jakobbotsch commented Oct 19, 2022

Uh oh!

jakobbotsch commented Oct 19, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Oct 20, 2022

Uh oh!

azure-pipelinesBot commented Oct 20, 2022

Uh oh!

jakobbotsch commented Oct 20, 2022

Uh oh!

jakobbotsch commented Oct 21, 2022

Uh oh!

jakobbotsch commented Oct 21, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jakobbotsch commented Oct 18, 2022•
edited
Loading

jakobbotsch commented Oct 19, 2022•
edited
Loading