-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Introduce factory methods to create assertions #123845
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
Conversation
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
src/coreclr/jit/assertionprop.cpp:1467
Compiler::optAddVnAssertionMappingis defined asconstbut it mutatesoptValueNumToAsserts. This is not logically const and can be surprising for readers/tools; consider making it non-const (and update the declaration accordingly).
void Compiler::optAddVnAssertionMapping(ValueNum vn, AssertionIndex index) const
{
ASSERT_TP* cur = optValueNumToAsserts->LookupPointer(vn);
if (cur == nullptr)
{
optValueNumToAsserts->Set(vn, BitVecOps::MakeSingleton(apTraits, index - 1));
}
else
{
BitVecOps::AddElemD(apTraits, *cur, index - 1);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
|
@AndyAyersMS @jakobbotsch @dotnet/jit-contrib PTAL a clean up (no diffs) |
AndyAyersMS
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it still makes sense to drop the assertion count for large methods like this.
When I did something similar for local AP I used the metrics data to see if there was some way to assess how many assertions were being created vs various metrics.
See #109481 (comment) for some examples.
You might want to try something similar and see if BB count is well correlated or if adding in lcl vars or tracked lcl vars suggests when you can use smaller sizes without losing much if anything (which would help TP).
For global AP the vast majority of all assertions are "obj is not null" ( New diffs - slightly better TP, zero size diffs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
eb19ae1 to
d784ed0
Compare
My feedback about table sizes was meant for #123856 -- was looking at them both at the same time. |
Zero-diff clean up change.
AssertionDsc::Create*factory methods. The plan is to removeoptCreateAssertionentirely. This gives a more precise control on which fields are relevant and which are not.AssertionDsc*withconst AssertionDsc&everywhere, marked many related functions asconst. This makes code more memory safe (no unexpected mutations) and actually improves TP a bit.Ideas for a follow up:
memcmpfor AssertionDsc::Equals (if we pack it)?No diffs