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

Zero-diff part of "Use SSA-based ComputeRange" #112853

Merged
merged 11 commits into from
Feb 28, 2025
Merged

Conversation

EgorBo
Copy link
Member

@EgorBo EgorBo commented Feb 24, 2025

Extracted from #112824 for simpler code review

@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 Feb 24, 2025
Copy link
Contributor

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

@EgorBo EgorBo marked this pull request as ready for review February 24, 2025 12:35
@Copilot Copilot bot review requested due to automatic review settings February 24, 2025 12:35

Choose a reason for hiding this comment

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

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

@EgorBo
Copy link
Member Author

EgorBo commented Feb 24, 2025

@jakobbotsch @AndyAyersMS @dotnet/jit-contrib PTAL, zero-diff change. Just preparations for using RangeCheck in assertprop (in #112824):

  1. Hid all maps under lazy-init getters (these maps are cleaned on every GetRange call, so the state is not shareable between phases).
  2. RangeCheck becomes a singleton instance - this helps to reduce TP impact and allocations when it's called from Assertprop
  3. Removed verbose SSA validation - it's quite ad-hoc and messy, also, it's an additional state that I had to reset between phases. RangeCheck used to be the last phase to use SSA, but it's not the case today so if we need it, we have to come up with some generic SSA validation and use it everywhere.
  4. Propagated block into various optAssertionProp_* that I'll need.

CI failures are unrelated.

Copy link
Member

@AndyAyersMS AndyAyersMS left a comment

Choose a reason for hiding this comment

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

I guess we're trying to economize by keeping the collection backbones around once we've allocated them.

Could we make it clearer which parts of the range check state are durable and which parts are not? Eg split out the more transient parts into a caller-supplied struct or something?

Or make it harder to accidentally call into the wrong part of range check?

@EgorBo
Copy link
Member Author

EgorBo commented Feb 27, 2025

@AndyAyersMS I have reworked everything and made all members in Rangecheck private except these three:

// Entry point for RangeCheck phase
bool OptimizeRangeChecks();

// GetRange for an arbitrary tree. Slow, is based on SSA.
// (perhaps, can be reworked someday to be purely VN-based)
// Resets all caches on entry.
bool TryGetRange(BasicBlock* block, GenTree* expr, Range* pRange);

// Cheaper version of TryGetRange that is based only on incoming assertions.
// Does not need any internal state - hence, static
static bool TryGetRangeFromAssertions(Compiler* comp, ValueNum num, ASSERT_VALARG_TP assertions, Range* pRange);

Also, addressed your feedback around clearing caches when we haven't created them yet by introducing Clear<map name>() methods.

DoesOverflow is merged into TryGetRange

@EgorBo EgorBo merged commit 949ad0f into dotnet:main Feb 28, 2025
112 checks passed
@EgorBo EgorBo deleted the rngchk-2-nodiff branch February 28, 2025 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.

2 participants