Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert more jit phases to opt into common post phase checks #74041

Merged
merged 13 commits into from
Aug 19, 2022

Conversation

AndyAyersMS
Copy link
Member

There are 20-odd phases that haven't yet been converted to running the common post phase checks. This converts the first half of them.

Note this is a bit of a lie. We actually don't run most checks until morph, but a future change will work on enabling checks throughout the phase list.

I also did a bit of cleanup here and there; most notably we no longer needed fgResetImplicitByRefRefCount as it was just setting the counts the values they already had.

Contributes to #2109.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Aug 17, 2022
@ghost ghost assigned AndyAyersMS Aug 17, 2022
@ghost
Copy link

ghost commented Aug 17, 2022

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

Issue Details

There are 20-odd phases that haven't yet been converted to running the common post phase checks. This converts the first half of them.

Note this is a bit of a lie. We actually don't run most checks until morph, but a future change will work on enabling checks throughout the phase list.

I also did a bit of cleanup here and there; most notably we no longer needed fgResetImplicitByRefRefCount as it was just setting the counts the values they already had.

Contributes to #2109.

Author: AndyAyersMS
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@AndyAyersMS
Copy link
Member Author

@dotnet/jit-contrib PTAL


if (returnSpillVarDsc->lvSingleDef)
{
lvaUpdateClass(lvaInlineeReturnSpillTemp, retExprClassHnd, impInlineInfo->retExprClassHndIsExact);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like this change factors into the decision about returning MODIFIED_NOTHING below.

Also, presumably doing this before this phase is equivalent to doing it after, where it was being done before?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't been trying to track modifications that we don't check and/or dump anywhere.

{
#ifdef DEBUG
if (verbose)
if (verbose && !isPhase)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(not related to this line)

Interesting that we don't consider removing BBF_REMOVED blocks as modified but I guess that makes sense.

}

//-------------------------------------------------------------
// fgComputeMissingBlockWeights: determine weights for blocks
// that were not profiled and do not yet have weights.
//
// Arguments
// return weight [out] - sum of weights for all return and throw blocks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit

Suggested change
// return weight [out] - sum of weights for all return and throw blocks
// returnWeight [out] - sum of weights for all return and throw blocks

fgVerifyHandlerTab();
fgDebugCheckBBlist();
#endif // DEBUG
return madeChanges ? PhaseStatus::MODIFIED_EVERYTHING : PhaseStatus::MODIFIED_NOTHING;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of tracking madeChanges you could just use:

Suggested change
return madeChanges ? PhaseStatus::MODIFIED_EVERYTHING : PhaseStatus::MODIFIED_NOTHING;
return (compHndBBtabCount > 0) ? PhaseStatus::MODIFIED_EVERYTHING : PhaseStatus::MODIFIED_NOTHING;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@@ -221,7 +223,7 @@ void Phase::PostPhase(PhaseStatus status)
// cse
// assertion prop
// range check
// update flow
// PHASE_OPT_UPDATE_FLOW_GRAPH,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to un-comment this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had it that way at one point, but it caused loop table validity asserts.

Will revisit as part of round 2 when I try converting the rest of the phases.

@AndyAyersMS
Copy link
Member Author

SPMI failures are likely from #64497, will merge up next time I push.

@AndyAyersMS
Copy link
Member Author

/azp run runtime-coreclr jitstress

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@AndyAyersMS
Copy link
Member Author

All the jit stress failures are arm/arm64 infra issues. SPMI are timeouts / and or rerun failures because of pre-existing logs.

Going to roll the dice here and say there's no reason to try and get all those green.

@AndyAyersMS AndyAyersMS merged commit 9cd1a32 into dotnet:main Aug 19, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Sep 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants