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.

Sign up for GitHub

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

Jump to bottom

Test failure: JIT/HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_ro/ArmBase.Arm64_ro.sh #39618

Closed
v-haren opened this issue Jul 20, 2020 · 4 comments · Fixed by #39753
Closed

Test failure: JIT/HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_ro/ArmBase.Arm64_ro.sh #39618

v-haren opened this issue Jul 20, 2020 · 4 comments · Fixed by #39753
Assignees
@echesakov
Labels
arch-arm64 area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI JitStress CLR JIT issues involving JIT internal stress modes
Milestone
5.0.0

Comments

@v-haren
Copy link

v-haren commented Jul 20, 2020 •
edited
Loading

failed in job: runtime-coreclr jitstress-isas-arm 20200718.1

failed tests:
JIT/HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_ro/ArmBase.Arm64_ro.sh
JIT/HardwareIntrinsics/Arm/ArmBase/ArmBase_ro/ArmBase_ro.sh
JIT/HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_r/ArmBase.Arm64_r.sh
JIT/HardwareIntrinsics/Arm/ArmBase/ArmBase_r/ArmBase_r.sh

Error message

Return code:      1
Raw output file:      /root/helix/work/workitem/JIT/HardwareIntrinsics/Reports/JIT.HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_ro/ArmBase.Arm64_ro.output.txt
Raw output:
BEGIN EXECUTION
/root/helix/work/correlation/corerun ArmBase.Arm64_ro.dll ''
Supported ISAs:
  AdvSimd:   False
  Aes:       False
  ArmBase:   False
  Crc32:     False
  Dp:        False
  Rdm:       False
  Sha1:      False
  Sha256:    False

Beginning test case LeadingSignCount.Int32 at 7/18/2020 8:37:01 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Beginning test case LeadingSignCount.Int64 at 7/18/2020 8:37:02 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Beginning test case LeadingZeroCount.Int64 at 7/18/2020 8:37:02 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Beginning test case LeadingZeroCount.UInt64 at 7/18/2020 8:37:02 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Beginning test case ReverseElementBits.Int64 at 7/18/2020 8:37:02 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Beginning test case ReverseElementBits.UInt64 at 7/18/2020 8:37:02 PM
Random seed: 20010415; set environment variable CORECLR_SEED to this value to repro

Beginning scenario: RunUnsupportedScenario
Beginning scenario: RunBasicScenario_UnsafeRead
ERROR!!!-System.Exception: One or more scenarios did not complete as expected.

Ending test case at 7/18/2020 8:37:02 PM
Expected: 100
Actual: 0
END EXECUTION - FAILED
Test Harness Exitcode is : 1
To run the test:
> set CORE_ROOT=/root/helix/work/correlation
> /root/helix/work/workitem/JIT/HardwareIntrinsics/Arm/ArmBase.Arm64/ArmBase.Arm64_ro/ArmBase.Arm64_ro.sh
Expected: True
Actual:   False


Stack trace
   at JIT_HardwareIntrinsics._Arm_ArmBase_Arm64_ArmBase_Arm64_ro_ArmBase_Arm64_ro_._Arm_ArmBase_Arm64_ArmBase_Arm64_ro_ArmBase_Arm64_ro_sh() in /__w/1/s/artifacts/tests/coreclr/Linux.arm64.Checked/TestWrappers/JIT.HardwareIntrinsics/JIT.HardwareIntrinsics.XUnitWrapper.cs:line 2371
@v-haren v-haren added the JitStress CLR JIT issues involving JIT internal stress modes label Jul 20, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI untriaged New issue has not been triaged by the area owner labels Jul 20, 2020
@JulieLeeMSFT JulieLeeMSFT removed the untriaged New issue has not been triaged by the area owner label Jul 20, 2020
@JulieLeeMSFT JulieLeeMSFT added this to the 5.0.0 milestone Jul 20, 2020
@echesakov
Copy link
Contributor

The issue here is that ArmBase intrinsics (e.g. LeadingZeroCount, ReverseElementBits) are pre-jitted and when COMPlus_EnableHWIntrinsic=0 JIT emits a call to a pre-jitted version of the intrinsic effectively ignoring the COMPlus variable setting. I believe this started failing after #38060

cc @tannergooding @dotnet/jit-contrib

@echesakov
Copy link
Contributor

The following are more detailed analysis what is happening.

During impImportCall on LeadingZeroCount since COMPlus_EnableHWIntrinsic=0 the call to impIntrinsic would return nullptr with the following stack trace:

(lldb) bt
* thread #1, name = 'corerun', stop reason = step over
  * frame #0: 0x0000007fb3f7ec44 libclrjit.so`Compiler::impUnsupportedNamedIntrinsic(this=0x0000005555617e98, helper=185, method=0x0000007f3e58c950, sig=0x0000007fffffbcf0, mustExpand=false) at importer.cpp:4672:9
    frame #1: 0x0000007fb3f7ca20 libclrjit.so`Compiler::impIntrinsic(this=0x0000005555617e98, newobjThis=0x0000000000000000, clsHnd=0x0000007f3e58ca70, method=0x0000007f3e58c950, sig=0x0000007fffffbcf0, methodFlags=1107296264, memberRef=167772216, readonlyCall=false, tailCall=false, pConstrainedResolvedToken=0x0000000000000000, constraintCallThisTransform=CORINFO_NO_THIS_TRANSFORM, pIntrinsicID=0x0000007fffff9944, isSpecialIntrinsic=0x0000007fffff9937) at importer.cpp:3545:24
    frame #2: 0x0000007fb3f877e0 libclrjit.so`Compiler::impImportCall(this=0x0000005555617e98, opcode=CEE_CALL, pResolvedToken=0x0000007fffffbc00, pConstrainedResolvedToken=0x0000000000000000, newobjThis=0x0000000000000000, prefixFlags=0, callInfo=0x0000007fffffbce0, rawILOffset=27) at importer.cpp:7730:20
    frame #3: 0x0000007fb3f97968 libclrjit.so`Compiler::impImportBlockCode(this=0x0000005555617e98, block=0x0000005555619bf8) at importer.cpp:14162:27
    frame #4: 0x0000007fb3fa1cc4 libclrjit.so`Compiler::impImportBlock(this=0x0000007fffffc0f8, pParam=0x0000007fffffc108)::$_1::operator()(Compiler::impImportBlock(BasicBlock*)::FilterVerificationExceptionsParam*) const at importer.cpp:17268:24
    frame #5: 0x0000007fb3fa0d7c libclrjit.so`Compiler::impImportBlock(this=0x0000005555617e98, block=0x0000005555619bf8) at importer.cpp:17278:5
    frame #6: 0x0000007fb3fa33cc libclrjit.so`Compiler::impImport(this=0x0000005555617e98) at importer.cpp:18366:13
    frame #7: 0x0000007fb3ef62a4 libclrjit.so`Compiler::fgImport(this=0x0000005555617e98) at flowgraph.cpp:7155:5

and, as a consequence, we treat the call as a regular call:

(lldb)
Process 10 stopped
* thread #1, name = 'corerun', stop reason = step over
    frame #0: 0x0000007fb3f880ac libclrjit.so`Compiler::impImportCall(this=0x0000005555617e98, opcode=CEE_CALL, pResolvedToken=0x0000007fffffbc00, pConstrainedResolvedToken=0x0000000000000000, newobjThis=0x0000000000000000, prefixFlags=0, callInfo=0x0000007fffffbce0, rawILOffset=27) at importer.cpp:7945:52
   7942             case CORINFO_CALL:
   7943             {
   7944                 // This is for a non-virtual, non-interface etc. call
-> 7945                 call = gtNewCallNode(CT_USER_FUNC, callInfo->hMethod, callRetTyp, nullptr, ilOffset);
                                                           ^
   7946
   7947                 // We remove the nullcheck for the GetType call instrinsic.
   7948                 // TODO-CQ: JIT64 does not introduce the null check for many more helper calls
(lldb) bt
* thread #1, name = 'corerun', stop reason = step over
  * frame #0: 0x0000007fb3f880ac libclrjit.so`Compiler::impImportCall(this=0x0000005555617e98, opcode=CEE_CALL, pResolvedToken=0x0000007fffffbc00, pConstrainedResolvedToken=0x0000000000000000, newobjThis=0x0000000000000000, prefixFlags=0, callInfo=0x0000007fffffbce0, rawILOffset=27) at importer.cpp:7945:52
    frame #1: 0x0000007fb3f97968 libclrjit.so`Compiler::impImportBlockCode(this=0x0000005555617e98, block=0x0000005555619bf8) at importer.cpp:14162:27
    frame #2: 0x0000007fb3fa1cc4 libclrjit.so`Compiler::impImportBlock(this=0x0000007fffffc0f8, pParam=0x0000007fffffc108)::$_1::operator()(Compiler::impImportBlock(BasicBlock*)::FilterVerificationExceptionsParam*) const at importer.cpp:17268:24
    frame #3: 0x0000007fb3fa0d7c libclrjit.so`Compiler::impImportBlock(this=0x0000005555617e98, block=0x0000005555619bf8) at importer.cpp:17278:5
    frame #4: 0x0000007fb3fa33cc libclrjit.so`Compiler::impImport(this=0x0000005555617e98) at importer.cpp:18366:13
    frame #5: 0x0000007fb3ef62a4 libclrjit.so`Compiler::fgImport(this=0x0000005555617e98) at flowgraph.cpp:7155:5

However, since LeadingZeroCount was pre-jitted we ended up calling the R2R code.

The correct behavior would be to discard the pre-jitted LeadingZeroCount, re-compile the code with the body as generated by impUnsupportedNamedIntrinsic(mustExpand=true) (i.e. effectively just throwing PlatformNotSupportedException):

        for (unsigned i = 0; i < sig->numArgs; i++)
        {
            impPopStack();
        }

        return gtNewMustThrowException(helper, JITtype2varType(sig->retType), sig->retTypeClass);

@kunalspathak
Copy link
Member

Need to investigate what happens to prejitted methods containing SSE2 APIs and when ran with COMPlus_EnableHWIntrinsic=0. Same thing should happen for ARM64 as well.

@echesakov
Copy link
Contributor

Need to investigate what happens to prejitted methods containing SSE2 APIs and when ran with COMPlus_EnableHWIntrinsic=0. Same thing should happen for ARM64 as well.

We don't pre-jit SSE2 on x64. Below are the output of x64 сrossgen running on S.P.C.dll

Compiling method System.Runtime.Intrinsics.X86.X86Base.get_IsSupported
Skipped due to being a hardware intrinsic
Compiling method System.Runtime.Intrinsics.X86.X86Base.BitScanForward
Skipped due to being a hardware intrinsic
Compiling method System.Runtime.Intrinsics.X86.X86Base.BitScanReverse
Skipped due to being a hardware intrinsic
Compiling method System.Runtime.Intrinsics.X86.Sse2.Xor
Skipped due to being a hardware intrinsic
Compiling method System.Runtime.Intrinsics.X86.Sse2.Xor
Skipped due to being a hardware intrinsic
Compiling method System.Runtime.Intrinsics.X86.Sse2.Xor
Skipped due to being a hardware intrinsic

@echesakov echesakov assigned echesakov and unassigned kunalspathak Jul 22, 2020
@echesakov echesakov mentioned this issue Jul 22, 2020
Merged
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@echesakov echesakov

Labels
arch-arm64 area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI JitStress CLR JIT issues involving JIT internal stress modes
Projects
None yet
Milestone
5.0.0
Development

Successfully merging a pull request may close this issue.

[Arm64] Don't generate hardware intrinsic method bodies echesakov/runtime
5 participants
@echesakov @kunalspathak @v-haren @Dotnet-GitSync-Bot @JulieLeeMSFT