JIT: Set edge likelihoods during patchpoint transformation - #97897

Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged

JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom
amanasifkhalid:likelihood-jitstress

Conversation

@amanasifkhalid

@amanasifkhalidamanasifkhalid commented Feb 2, 2024

Copy link
Copy Markdown
Contributor

Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.

@ghostghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Feb 2, 2024
@ghost

ghost commented Feb 2, 2024

Copy link
Copy Markdown

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

Issue Details

Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.

Author:amanasifkhalid
Assignees:-
Labels:

area-CodeGen-coreclr

Milestone:-

@amanasifkhalid

amanasifkhalid commented Feb 2, 2024

Copy link
Copy Markdown
ContributorAuthor

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

@azure-pipelines

azure-pipelinesBot commented Feb 2, 2024

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch
jakobbotsch reviewed Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp Outdated
Comment on lines +163 to +164
trueEdge->setLikelihood(0.5);
falseEdge->setLikelihood(0.5);

@jakobbotschjakobbotschFeb 2, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?

@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?

Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.

The test actually passing should be very rare (I believe the threshold is 1/10000).

Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?

@jakobbotschjakobbotschFeb 2, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...

@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.

@jakobbotschjakobbotschFeb 2, 2024•
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.

@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.

@amanasifkhalid

amanasifkhalid commented Feb 2, 2024

Copy link
Copy Markdown
ContributorAuthor

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

@azure-pipelines

azure-pipelinesBot commented Feb 2, 2024

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

jakobbotsch
jakobbotsch reviewed Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp Outdated
@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid

amanasifkhalid commented Feb 2, 2024•
edited
Loading

Copy link
Copy Markdown
ContributorAuthor

@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.

What do you think?

@amanasifkhalid

amanasifkhalid commented Feb 2, 2024

Copy link
Copy Markdown
ContributorAuthor

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

@azure-pipelines

azure-pipelinesBot commented Feb 2, 2024

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

@AndyAyersMS

AndyAyersMS commented Feb 2, 2024

Copy link
Copy Markdown
Member

@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.

What do you think?

That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024
Closed
Closed
Closed
@amanasifkhalid

amanasifkhalid commented Feb 5, 2024

Copy link
Copy Markdown
ContributorAuthor

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

@azure-pipelines

azure-pipelinesBot commented Feb 5, 2024

Copy link
Copy Markdown
Azure Pipelines successfully started running 2 pipeline(s).

@amanasifkhalid

amanasifkhalid commented Feb 5, 2024

Copy link
Copy Markdown
ContributorAuthor

Failures are known.

@amanasifkhalid
amanasifkhalid merged commit 67604d3 into dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid deleted the likelihood-jitstress branch February 5, 2024 19:34
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'

3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
JIT: Set edge likelihoods during patchpoint transformation - #97897
Merged
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Feb 5, 2024
Merged
JIT: Set edge likelihoods during patchpoint transformation#97897
amanasifkhalid merged 6 commits into
dotnet:mainfrom 
amanasifkhalid:likelihood-jitstress
Conversation
@amanasifkhalid
@amanasifkhalidamanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

Contributor
Fixes#97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
@ghostghost
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Feb 2, 2024
@ghost
ghost
commented
Feb 2, 2024

Copy link


Copy Markdown

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #97892. During patchpoint expansion, make sure to set edge likelihoods for transformed blocks.
Author:amanasifkhalid
Assignees:-
Labels:
area-CodeGen-coreclr
Milestone:-
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated


Comment on lines

+163
 to 
+164

 trueEdge->setLikelihood(0.5);
 falseEdge->setLikelihood(0.5);
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

The test actually passing should be very rare (I believe the threshold is 1/10000). Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Also, isn't trueEdge always going to be the BBJ_ALWAYS edge inserted by fgSplitBlockAtBeginning above, so the check here is a bit meaningless?
Ah you're right, so trueEdge should always have an edge likelihood here. I'll remove the branch.
The test actually passing should be very rare (I believe the threshold is 1/10000).
Is there any value to being more precise than 0.1/0.9 for trueEdge/falseEdge's likelihoods?
@jakobbotschjakobbotschFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

In tier0? Doubtful. Also 1/10000 is not entirely accurate since I believe multiple patchpoints share the counter, but @AndyAyersMS can correct me if I'm wrong...
@amanasifkhalidamanasifkhalidFeb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

I see below this snippet that helperBlock inherits 1% of block's weight; should we have the edge likelihoods match that? So trueEdge is 0.99, and falseEdge is 0.01.
@jakobbotschjakobbotschFeb 2, 2024•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Makes sense to me to be consistent with that. On further look it looks like TC_OnStackReplacement_InitialCounter is 1000. Not sure if the mismatch is intentional or not; in a way, the most accurate guess we could make is probably 1 / <that value>, but feel free to stick with the 1% here.
@AndyAyersMSAndyAyersMSFeb 2, 2024

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

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

Overall it probably doesn't matter since (at least for now) we only have patchpoints in unoptimized code. I guess I'd go with the precedent already there and use the 0.99/0.01 split.
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
jakobbotsch
jakobbotsch
reviewed
Feb 2, 2024
View reviewed changes
Comment threadsrc/coreclr/jit/patchpoint.cpp
Outdated

@amanasifkhalid@jakobbotsch
Update src/coreclr/jit/patchpoint.cpp
56696dc
Co-authored-by: Jakob Botsch Nielsen <Jakob.botsch.nielsen@gmail.com>
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024•

edited

Loading

Copy link


Copy Markdown

ContributorAuthor
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
@amanasifkhalid
amanasifkhalid
commented
Feb 2, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 2, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@AndyAyersMS
AndyAyersMS
commented
Feb 2, 2024

Copy link


Copy Markdown

Member
@AndyAyersMS this isn't wholly related to this change, but I wonder if we should initialize all edge likelihoods to (1.0 / NumSucc()) (maybe in fgLinkBasicBlocks), so that if we encounter an edge without a likelihood, it's because we didn't set it during/after some call to fgAddRefPred in that phase. In the follow-up work to #97740, I'm encountering methods where we initialize the likelihoods using profile data in fgIncorporateProfileData, and then while inlining a method call, we don't initialize the new blocks' edge likelihoods due to a lack of profile data for the inlinee. If we have some guarantee that likelihoods will always be initialized regardless of whether fgIncorporateProfileData can leverage profile data, then I think the logic for setting/updating likelihoods in later phases will be simpler. If our initial guesses for the successor edges of BBJ_COND, BBJ_SWITCH, etc don't match the profile data, then fgIncorporateProfileData can just overwrite them.
What do you think?
That's more or less what happens in profile synthesis, with the potential of being a bit more clever over time. Right now it is optional and off by default. So you could try turning it on when profile data is absent (just "AssignLikelihoods", not full synthesis, for now).

This was referenced Feb 3, 2024

Closed


Closed


Closed

@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress
@azure-pipelines
azure-pipelinesBot
commented
Feb 5, 2024

Copy link


Copy Markdown


Azure Pipelines successfully started running 2 pipeline(s).
@amanasifkhalid
amanasifkhalid
commented
Feb 5, 2024

Copy link


Copy Markdown

ContributorAuthor
Failures are known.
@amanasifkhalid
amanasifkhalid
merged commit 67604d3
into
dotnet:mainFeb 5, 2024
@amanasifkhalid
amanasifkhalid
deleted the

likelihood-jitstress

branch
February 5, 2024 19:34
@github-actionsgithub-actionsBot
locked and limited conversation to collaborators
Mar 7, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@AndyAyersMSAndyAyersMSAndyAyersMS left review comments
@jakobbotschjakobbotschjakobbotsch approved these changes

Assignees

@amanasifkhalidamanasifkhalid

Labels

area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

[jitstress] Assertion failed '!"Inconsistent profile data"'


3 participants

@amanasifkhalid@AndyAyersMS@jakobbotsch