runtime: Coredistools failure to disassemble vextracti64x4

SuperPMI is reporting an asm diff in:

JIT.HardwareIntrinsics.General._Vector512_1.VectorGetAndWithLowerAndUpper__GetAndWithLowerAndUpperByte:RunBasicScenario():this

but no textual diff, for both x64 and x86. For x64, it is in 236d7997-3d71-45f9-b7d7-5241ad89a56f.windows.x64\coreclr_tests.run.windows.x64.checked.mch.

The superpmi log shows:

[10:34:40] ERROR: Decode Failure Left@ offset 1fb4f77e456
[10:34:40] ERROR: Decode Failure Right@ offset 1fb52ec6816
[10:34:40] ERROR: Decode Failure Left@ offset 1fb4f77e456
[10:34:40] ERROR: Decode Failure Right@ offset 1fb52ec6816

The issue is that coredistools is failing to disassemble:

62D3BD483BF001       vextracti64x4 ymm8, zmm6, 1

coredistools was last updated based on LLVM 13.0.1 in March 2022 with https://github.com/dotnet/jitutils/pull/351 (and related). The most recent version is LLVM 16.0.0 released March 2023 (https://releases.llvm.org/). Does it have a fix for this?

I verified that this disassembles correctly in Visual Studio.

Are there other cases where vextracti64x4 is properly decoded so it’s not all cases, just some?

If we can’t update coredistools with a fix, we’ll have to do something so SuperPMI doesn’t display spurious diffs. E.g., filter out the failing MCs.

@dotnet/avx512-contrib @dotnet/jit-contrib

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

Presumably the test that you’re looking for didn’t run

@markples There are multiple things going on here, but the core problem is the important test here, that took down the merged group, did not get reported as failing (and in fact the entire group did not get reported as failing).

There’s an issue where one level needs to report at “success” to avoid helix retrying the job. This isn’t an area that I understand - those you’ve already tagged (plus maybe @jkoritzinsky?) should know more.

I opened https://github.com/dotnet/runtime/issues/85056 to track the CI infrastructure problem (of not reporting this test failure)

Also, @ivdiazsa – it looks like XUnitLogChecker is ignoring the test run exit code