Test failure: JIT\\Regression\\JitBlue\\GitHub_35821\\GitHub_35821\\GitHub_35821.cmd #36206

Activity

1. v-haren

   added

   JitStressCLR JIT issues involving JIT internal stress modesCLR JIT issues involving JIT internal stress modes

   on May 11, 2020
2. Dotnet-GitSync-Bot

   added

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

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on May 11, 2020
3. BruceForstall

   added this to the 5.0 milestone on May 11, 2020
4. BruceForstall

   removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on May 11, 2020
5. BruceForstall commented on May 11, 2020

   

   BruceForstall

   on May 11, 2020

   Contributor

   More actions

   From CoreCLR Windows_NT arm64 Checked jitstress_isas_nohwintrinsic_nosimd,

   set COMPlus_TieredCompilation=0
   set COMPlus_EnableHWIntrinsic=0
   set COMPlus_FeatureSIMD=0
   

   @echesakovMSFT @kunalspathak @tannergooding @CarolEidt
6. kunalspathak commented on May 11, 2020

   

   kunalspathak

   on May 11, 2020

   Contributor

   More actions

   I will take a look. This is the new test that I added last week.
7. kunalspathak commented on May 12, 2020

   

   kunalspathak

   on May 12, 2020

   Contributor

   More actions

   I believe this is an existing issue that got exposed because of this test case. The C# version of the test is simple. We just need to create Vector64.Create(double_imm) and pass it to method.

   Test3(Vector64.Create(23.1));
   		
   [MethodImpl(MethodImplOptions.NoInlining)]
   public static void Test3(Vector64<double> data) {}

   This repros only if COMPlus_FeatureSIMD=0. With that, we inline Vector64.Create(double value) implementation which is Unsafe.As() as seen here. Then we try to constant propagate the value of double in assertion prop. But when we try to do it same for the tree node that represents the result, we hit assert here because tree->TypeGet() == TYP_SIMD8. I think the right fix would be to not do constant propagation in such case. I didn't see an easy way to repro it for other types like TYP_SIMD16, etc. because we might not inline the implementation of Vector128.Create(double).

   @briansull , @BruceForstall - can one of you confirm my understanding?
   @tannergooding - I assume that even you would hit this in your #36267.
8. CarolEidt commented on May 13, 2020

   

   CarolEidt

   on May 13, 2020

   Contributor

   More actions

   I believe that the fundamental problem here is the retyping that we do of TYP_SIMD8 return types as TYP_DOUBLE. I believe that the right answer here is to never retype TYP_SIMD return values as TYP_DOUBLE, just as we're moving away from retyping other struct return types. I think @sandreenko might also want to comment here.
9. sandreenko

   self-assigned this

   on May 13, 2020
10. sandreenko commented on May 13, 2020

    

    sandreenko

    on May 13, 2020

    Contributor

    More actions

    The issue should be resolved with JitDoOldStructRetyping = false, I will check that once I finish support for arm32.

    Thanks for the analysis.
11. sandreenko

    closed this as completedin #38855on Jul 8, 2020
12. sandreenko

    added a commit that references this issue on Jul 8, 2020

    Reenable fixed tests after noRetyping and similar changes. (#38855)

    ...

    This issue will close once commit 9bb997b is merged into the 'main' branch.

    9bb997b
13. ghost locked as resolved and limited conversation to collaborators on Dec 9, 2020