Disabling disasm checks under certain testing environments - #76202

Merged
TIHan merged 10 commits into
dotnet:mainfrom
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged

Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom
TIHan:filecheck-ci-fixes

Conversation

@TIHan

@TIHanTIHan commented Sep 26, 2022•
edited
Loading

Copy link
Copy Markdown
Contributor

@ghost

ghost commented Sep 26, 2022

Copy link
Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghostghost assigned TIHanSep 26, 2022
@TIHan

TIHan commented Sep 26, 2022

Copy link
Copy Markdown
ContributorAuthor

@dotnet/jit-contrib @EgorBo This is ready.

@danmoseleydanmoseley added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Sep 26, 2022
@ghost

ghost commented Sep 26, 2022

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

Should resolve:

Description

We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).

Author:TIHan
Assignees:TIHan
Labels:

area-CodeGen-coreclr

Milestone:-

@markples

markples commented Sep 26, 2022

Copy link
Copy Markdown
Contributor

Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?

markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets Outdated
<PropertyGroup>
<HasBashDisasmCheck>false</HasBashDisasmCheck>
<HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
<HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

@markplesmarkplesSep 26, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.

@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.

@markplesmarkplesSep 27, 2022•
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>

markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets Outdated
<HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

<GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
<HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>

@markplesmarkplesSep 26, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?

@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?

@markplesmarkplesSep 27, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps

markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
<BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
@(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then

@markplesmarkplesSep 26, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.

Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.

@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.

@markplesmarkplesSep 27, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.

I don't think it's too bad because you already have the script syntax. Something like

<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:

if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples reviewed Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets Outdated
@TIHan

TIHan commented Sep 26, 2022

Copy link
Copy Markdown
ContributorAuthor

Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?

For right now, we should only enable disasm checks for test modes that have predictable codegen.

@markples

markples commented Sep 27, 2022•
edited
Loading

Copy link
Copy Markdown
Contributor

For right now, we should only enable disasm checks for test modes that have predictable codegen.

I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.

But they are different from "normal optimized", which perhaps is what you mean for "right now"?

EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.

@TIHan

TIHan commented Sep 27, 2022

Copy link
Copy Markdown
ContributorAuthor

I just want to know what is expected, what the next steps are, etc.

  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.

@markples

markples commented Sep 27, 2022

Copy link
Copy Markdown
Contributor

...
2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
...

Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)

markples
markples approved these changes Sep 27, 2022
View reviewed changes

@markplesmarkples left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully

@tannergoodingtannergooding mentioned this pull request Sep 27, 2022
Merged
@TIHan

TIHan commented Sep 27, 2022

Copy link
Copy Markdown
ContributorAuthor

I believe you need to fix the two Incompatible vars

I'll make a separate PR for those.

@TIHan

TIHan commented Sep 27, 2022

Copy link
Copy Markdown
ContributorAuthor

CI is clean, failure is unrelated.

@TIHan
TIHan merged commit c6f5267 into dotnet:mainSep 27, 2022
@ghostghost locked as resolved and limited conversation to collaborators Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

1 more reviewer
@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley
, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley

, '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
Disabling disasm checks under certain testing environments - #76202
Merged
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Sep 27, 2022
Merged
Disabling disasm checks under certain testing environments#76202
TIHan merged 10 commits into
dotnet:mainfrom 
TIHan:filecheck-ci-fixes
Conversation
@TIHan
@TIHanTIHan
commented
Sep 26, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
@ghost
ghost
commented
Sep 26, 2022

Copy link


Copy Markdown

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.
@ghostghost
assigned TIHanSep 26, 2022
@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
@dotnet/jit-contrib @EgorBo This is ready.
@danmoseleydanmoseley
added
the 
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
label
Sep 26, 2022
@ghost
ghost
commented
Sep 26, 2022

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
Should resolve:
Description
We need to disable disasm checks if we are running under GCStress, TieredPGO, R2R, or on linux-musl(alpine).
Author:TIHan
Assignees:TIHan
Labels:
area-CodeGen-coreclr
Milestone:-
@markples
markples
commented
Sep 26, 2022

Copy link


Copy Markdown

Contributor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <PropertyGroup>
 <HasBashDisasmCheck>false</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64')">true</HasBashDisasmCheck>
 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I think you could fold the RunCrossGen2 check into GetDisasmCheckData and then not duplicate it on the bash/batch sides.
@TIHanTIHanSep 26, 2022

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.

Makes sense, I can also do the setting of GCStressIncompatible/HeapVerifyIncompatible well too.
@markplesmarkplesSep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

<EDIT: removed my comment about the Incompatible vars because it was wrong>
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

 <HasBashDisasmCheck Condition="'$(HasDisasmCheck)' == 'true' and '$(RuntimeFlavor)' == 'coreclr' and ('$(TargetOS)' == 'Linux' or '$(TargetOS)' == 'OSX') and ('$(TargetArchitecture)' == 'x64' or '$(TargetArchitecture)' == 'arm64') and '$(RunCrossGen2)' != 'true'">true</HasBashDisasmCheck>

 <GCStressIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</GCStressIncompatible>
 <HeapVerifyIncompatible Condition="'$(HasBashDisasmCheck)' == 'true'">true</HeapVerifyIncompatible>
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

I am curious to know the restrictions here. I thought these "just" impacted the runtime - do they change the codegen and therefore the disasm output?
@TIHanTIHanSep 26, 2022

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'm not 100% sure - we should probably ask.
@AndyAyersMS - Does GCStress/HeapVerify impact codegen at all?
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

To be clear - ok to disable and merge - just wondering about the future steps
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
 <BashDisasmCheckPostCommands Condition="'$(HasBashDisasmCheck)' == 'true'"><![CDATA[
if [[ -n $COMPlus_JitDisasm ]]; then
 @(DisasmCheckFiles -> ' dotnet $CORE_ROOT/SuperFileCheck/SuperFileCheck.dll --csharp "%(Identity)" --allow-unused-prefixes --check-prefixes=CHECK,$(TargetArchitecture.ToUpperInvariant()),$(TargetArchitecture.ToUpperInvariant())-$(TargetOS.ToUpperInvariant()) --dump-input-context 25 --input-file "$(BashDisasmOutputFile)"
if [[ ( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" ) ]]; then
@markplesmarkplesSep 26, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

This list is repeated four times, which will be difficult to maintain. For each of bash/batch, the two could be combined to one by defining a variable and using it in the two ifs.
Bash vs batch is difficult because the syntax is different. So perhaps instead of the above suggestion, the condition strings could be separately defined in msbuild variables and included twice in each script. Then those msbuild variables could be defined back-to-back so that it is clear that if you change one you need to change the other.
@TIHanTIHanSep 26, 2022

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'll see if I can clean it up - I'm just so afraid of getting the syntaxes wrong for each of them.
@markplesmarkplesSep 27, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

If you have a clean test run, merge without this to unblock outerloop, but please factor this afterwards.
I don't think it's too bad because you already have the script syntax. Something like
<PropertyGroup>
<DisasmBashCondition>(<![CDATA[( -z "$COMPlus_JitStress" ) && ( -z "$COMPlus_JitStressRegs" ) && ( -z "$COMPlus_TailcallStress" ) && ( "$COMPlus_TieredPGO" != "1" )]]></DisasmBashCondition>
<DisasmBatchCondition>"%COMPlus_JitStress%"=="" IF "%COMPlus_JitStressRegs%"=="" IF "%COMPlus_TailcallStress%"=="" IF NOT "%COMPlus_TieredPGO%" == "1"</DisasmBatchCondition>
</PropertyGroup>

Then the if lines:
if [[ $(DisasmBashCondition) ]]; then

IF $(DisasmBatchCondition) (

markples
markples
reviewed
Sep 26, 2022
View reviewed changes
Comment threadsrc/tests/Common/CLRTest.Jit.targets
Outdated

@TIHan
TIHan
commented
Sep 26, 2022

Copy link


Copy Markdown

ContributorAuthor
Are these being disabled because we don't want to test in those scenarios or because it will take more work to test them correctly? In other words, should we open work items to enable them?
For right now, we should only enable disasm checks for test modes that have predictable codegen.
@markples
markples
commented
Sep 27, 2022•

edited

Loading

Copy link


Copy Markdown

Contributor
For right now, we should only enable disasm checks for test modes that have predictable codegen.
I think these are all predictable, except perhaps tiering (not sure if available information can impact the codegen) and the timing and whether the next tier happens can vary by execution in some ways.
But they are different from "normal optimized", which perhaps is what you mean for "right now"?
EDIT - also fine to disable for now even if it should work - I just want to know what is expected, what the next steps are, etc.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I just want to know what is expected, what the next steps are, etc.
  1. Unblock outerloop runs
  2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)
For this PR, I'm waiting to see a failure on all x64 runs for the single test so I know this worked correctly. If so, I'll fix the test and hopefully we can get this merged in ASAP.
@markples
markples
commented
Sep 27, 2022

Copy link


Copy Markdown

Contributor
...

2. Document limitations on SuperFileCheck and disasm checking(including why we don't run for gcstress/jitstress/etc.)

...
Yes, this is what I'm asking about (and what the future work is to enable scenarios that ought to already work vs add new scenarios)
markples
markples
approved these changes
Sep 27, 2022
View reviewed changes
@markplesmarkples
left a comment


Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

approving but I believe you need to fix the two Incompatible vars by either not putting them in the other Target or modifying it to Return them as I wrote in the comment before it will work fully
@tannergoodingtannergooding
mentioned this pull request
Sep 27, 2022
 Merged

@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
I believe you need to fix the two Incompatible vars
I'll make a separate PR for those.
@TIHan
TIHan
commented
Sep 27, 2022

Copy link


Copy Markdown

ContributorAuthor
CI is clean, failure is unrelated.
@TIHan
TIHan
merged commit c6f5267
into
dotnet:mainSep 27, 2022
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 27, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers


1 more reviewer

@markplesmarkplesmarkples approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@TIHanTIHan

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.

3 participants

@TIHan@markples@danmoseley