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

Do not recost and rethread trees inside optRemoveRangeCheck #69895

Merged
merged 2 commits into from
May 27, 2022

Conversation

SingleAccretion
Copy link
Contributor

@SingleAccretion SingleAccretion commented May 27, 2022

All but one caller of the method (RangeCheck) already do so in their for (GenTree* node : stmt->TreeList()) loops, so it is not necessary.

Additionally, re-threading the statement, when combined with gtSetEvalOrder, can have the consequence of redirecting said loops, possibly causing them to miss some trees, which was observed in early propagation when working on removing GT_INDEX.

A few small diffs because we no longer recost when removing range checks in loop cloning, which is generally not necessary because cloning runs before the "global" costing is performed, except there is one quirk in gtSetEvalOrder which was looking at compCurStmt, and that is not set during fgSetBlockOrder.

Diffs.

All but one caller of the method (RangeCheck) already do so in
their "for (GenTree* node : stmt->TreeList())" loops, so it is
not necessary.

Additionally, re-threading the statement, when combined with
"gtSetEvalOrder", can have the consequence of redirecting said
loops, possibly causing them to miss some trees, which was
observed in early propagation when working on removing "GT_INDEX".

A few small diffs because we no longer recost when removing
range checks in loop cloning, which is generally not necessary
because cloning runs before the "global" costing is performed,
except there is one quirk in "gtSetEvalOrder" which was looking
as "compCurStmt", and that is not set during "fgSetBlockOrder".
Gets us back 0.13% (!!!) instructions according to PIN.
@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 May 27, 2022
@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label May 27, 2022
@ghost
Copy link

ghost commented May 27, 2022

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

Issue Details
All but one caller of the method (RangeCheck) already do so in
their "for (GenTree* node : stmt->TreeList())" loops, so it is
not necessary.

Additionally, re-threading the statement, when combined with
"gtSetEvalOrder", can have the consequence of redirecting said
loops, possibly causing them to miss some trees, which was
observed in early propagation when working on removing "GT_INDEX".

A few small diffs because we no longer recost when removing
range checks in loop cloning, which is generally not necessary
because cloning runs before the "global" costing is performed,
except there is one quirk in "gtSetEvalOrder" which was looking
as "compCurStmt", and that is not set during "fgSetBlockOrder".
Author: SingleAccretion
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@SingleAccretion SingleAccretion marked this pull request as ready for review May 27, 2022 16:24
@SingleAccretion
Copy link
Contributor Author

@dotnet/jit-contrib

@BruceForstall BruceForstall merged commit 1f303a1 into dotnet:main May 27, 2022
@SingleAccretion SingleAccretion deleted the RemoveRangeCheck-NoOrder branch May 27, 2022 21:11
@ghost ghost locked as resolved and limited conversation to collaborators Jun 27, 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 community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants