Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bad folding #54722

Merged
merged 2 commits into from
Jul 13, 2021
Merged

Fix bad folding #54722

merged 2 commits into from
Jul 13, 2021

Conversation

SingleAccretion
Copy link
Contributor

@SingleAccretion SingleAccretion commented Jun 25, 2021

GT_CNS_INT of TYP_INT on 64 hosts has an implicit contract: the value returned by IconValue() must "fit" into 32 bit
signed integer, i. e. static_cast<int>(IconValue()) == IconValue(). gtFoldExprConst was failing to uphold this contract when the target was 32 bit and the host was 64 bit.

Fix this by always truncating before calling SetIconValue().

I also added a test that reproduces the bad behavior, but to be effective it needs to be CG'ed on a 64 bit machine for a 32 bit target. I am not sure how to make sure that happens...

This change is not zero-diff. There were ~10 cases of either bad codegen or missed folding in the SPMI collections (all available for win-64 -> win-x86 cross-compilation), though none in the product code.

Found while looking at #53983.

GT_CNS_INT of TYP_INT on 64 hosts has an implicit contract:
the value returned by IconValue() must "fit" into 32 bit
signed integer, i. e. "static_cast<int>(IconValue()) == IconValue()".
gtFoldExprConst was failing to uphold this contract when the target
was 32 bit and the host was 64 bit.

Fix this by always truncating before calling SetIconValue().
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 25, 2021
@sandreenko
Copy link
Contributor

Sorry for a late response, the change looks good, but I would like to repro the issue.

I also added a test that reproduces the bad behavior, but to be effective it needs to be CG'ed on a 64 bit machine for a 32 bit target. I am not sure how to make sure that happens...

It should be pretty straightforward with this instruction: https://github.com/dotnet/runtime/blob/main/docs/workflow/debugging/coreclr/debugging-crossgen2.md

you run your test with set RunCrossgen2=1 it will give you a command like dotnet crossgen2.dll *.rsp, now change in the rsp file target from x64 to x86 and run with --jitpath path to clrjit_windows_x86_x64.dll and it should produce a native image compiled on x64 host for x86 target. I should have time this week to check that it reproduces the issue that you described if you don't do this first.

@SingleAccretion
Copy link
Contributor Author

@sandreenko Hmm, I suppose I was not really clear with the wording. What I meant is how to make sure the test is run the right way in CI, locally it can be reproduced easily with the usual AltJit setup.

That said, I have now checked that it does indeed reproduce with CG2 too.

Copy link
Contributor

@sandreenko sandreenko left a comment

Choose a reason for hiding this comment

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

LGTM

@SingleAccretion
Copy link
Contributor Author

Will rerun the CI one more time...

@SingleAccretion
Copy link
Contributor Author

Will rerun the CI one more time...

Well, that's not so many failures, so, progress :).

1) Build windows x64 Release SingleFile - mysterious build failures:

error NU1105: (NETCORE_ENGINEERING_TELEMETRY=Restore) Unable to find project information for 'D:\workspace\_work\1\s\src\libraries\System.Runtime.CompilerServices.Unsafe\src\System.Runtime.CompilerServices.Unsafe.ilproj'. If you are using Visual Studio, this may be because the project is unloaded or not part of the current solution so run a restore from the command-line. Otherwise, the project file may be invalid or missing targets required for restore.

2) CoreCLR Pri0 Runtime Tests Run OSX arm64 checked:

  • log1, log2 - tests succeeded, but the work item failed. Unclear why.
  • log3 - truncated log, likewise unclear what's up.

3) Installer Build and Test coreclr windows_x86 Debug - download failure, chalking up to #55449.

D:\workspace\_work\1\s\.dotnet\sdk\6.0.100-preview.4.21255.9\NuGet.targets(131,5): error : Failed to retrieve information about 'System.Spatial' from remote source 'https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/45bacae2-5efb-47c8-91e5-8ec20c22b4f8/nuget/v3/flat2/system.spatial/index.json'. [D:\workspace\_work\1\s\src\installer\tests\Assets\TestProjects\ResourceLookup\ResourceLookup.csproj]

@sandreenko
Copy link
Contributor

I saw these failures in other PRs, the infra is in a bad state, azure is trying to patch it up, but for now we have to merge on red.

@sandreenko sandreenko merged commit b744e1f into dotnet:main Jul 13, 2021
@SingleAccretion SingleAccretion deleted the Fix-Bad-Folding branch July 13, 2021 16:51
@ghost ghost locked as resolved and limited conversation to collaborators Aug 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants