8269580: assert(is_valid()) failed: invalid register (-1)

[jatin-bhateja]

• Assertion fails during emit phase of rep_stos instruction pattern on targets not supporting AVX512BW feature.
• Pattern is selected under following predication logic.
  predicate(!((ClearArrayNode*)n)->is_large() &&
  (UseAVX <= 2 || !VM_Version::supports_avx512vlbw()));
• Encoding block of this pattern passes a knoreg opmask register having a default encoding of -1, this later causes an assertion failure while assembling instruction operating over this register.
• Existing pattern rep_stos_evex should be able to handle case for AVX512 targets as instructions operating of opmask registers are anyways guarded by target feature checks.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8269580: assert(is_valid()) failed: invalid register (-1)

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Dean Long (@dean-long - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk17 pull/172/head:pull/172
$ git checkout pull/172

Update a local copy of the PR:
$ git checkout pull/172
$ git pull https://git.openjdk.java.net/jdk17 pull/172/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 172

View PR using the GUI difftool:
$ git pr show -t 172

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk17/pull/172.diff

[bridgekeeper]

👋 Welcome back jbhateja! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@jatin-bhateja The following label will be automatically applied to this pull request:

• hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[jatin-bhateja]

/label hotspot-compiler-dev

[openjdk]

@jatin-bhateja The hotspot-compiler label was already applied.

[mlbridge]

Webrevs

• 00: Full (300adbdc)

[vnkozlov]

Good.
What testing you did?

[openjdk]

@jatin-bhateja This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8269580: assert(is_valid()) failed: invalid register (-1)

Reviewed-by: kvn, dlong

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 34 new commits pushed to the master branch:

• ad27d9b: 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
• c67a7b0: 8269230: C2: main loop in micro benchmark never executed
• 962f1c1: 8262886: javadoc generates broken links with {@inheritdoc}
• f7ffd58: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog
• 4930ae9: 8268592: JDK-8262891 causes an NPE in Lint.augment
• 9ac63a6: 8262841: Clarify the behavior of PhantomReference::refersTo
• aba6c55: 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp
• 3e02224: 8269513: Clarify the spec wrt useOldISOCodes system property
• 0dc65d3: 8268897: [TESTBUG] compiler/compilercontrol/mixed/RandomCommandsTest.java must not fail on Command.quiet
• 3826012: 8268557: Module page uses unstyled table class
• ... and 24 more: https://git.openjdk.java.net/jdk17/compare/d9cb068f4ba85e2be2ebc14e89e739b0a2d90409...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[jatin-bhateja]

Good.
What testing you did?

No explicit test added since the code flow involves post allocation system initialization pattern which is very frequently exercised by almost all jtreg tests on KNL

[vnkozlov]

I have to test it in our system before you push. I will let you know results.

[vnkozlov]

tier1-3 testing passed.

[sviswa7]

VM_Version::supports_avx512vlbw() check is required otherwise MacroAssembler::clear_mem will assert. See the code snippet below. The assert is generated because the emovdqu with smaller than 512 bit vector width is not supported unless avx512vl() is available on the platform.
// Clearing constant sized memory using YMM/ZMM registers.
void MacroAssembler::clear_mem(Register base, int cnt, Register rtmp, XMMRegister xtmp, KRegister mask) {
assert(UseAVX > 2 && VM_Version::supports_avx512vlbw(), "");

[dean-long]

I can't convince myself that this fix is correct. The logic that controls when the mask register is used seems much more complicated that the predicate that guards it.

[jatin-bhateja]

Hi @sviswa7 , in all the following code paths originating from rep_stos and rep_stos_evex instruction pattern EVEX encoded instructions are guarded by compile time checks, thus it should be safe to remove AVX512BW check from rep_stos and just enable it for UseAVX <= 2.

• fill64_avx: Emits 64 byte mode if AVXThreshold=0 and UseAVX > 2 else it disintegrates to two 32 byte vex encoded moves.
• fill64_masked_avx : Is again guarded by AVX3Threshold = 0 and UseAVX > 2
• fill32_masked_avx : Guarded by UseAVX > 2 and AVX512VL == true.

This bug is related to clear operation over small non-constant length.

[dean-long]

@jatin-bhateja I see your point. With your change, the predicates are enough to prevent the assert. But I noticed an existing issue for both the small and large cases. The predicates do not prevent some cases where a mask register will be reserved when it isn't really needed. For example when UseFastStosb is TRUE or UseXMMForObjInit is FALSE. It seems like a good followup RFE.

[jatin-bhateja]

Hi @dean-long , yes extra opmask allocation will exist for non default control path, but its not a bug, and that's the penalty of packing mutiple flows in one pattern. We can do more cleanup in this flow as suggested.

[jatin-bhateja]

/integrate

[openjdk]

Going to push as commit 4bbf11d.
Since your change was applied there have been 37 commits pushed to the master branch:

• 54dd510: 8269704: Typo in j.t.Normalizer.normalize()
• a8385fe: 8269354: javac crashes when processing parenthesized pattern in instanceof
• c16d1fc: 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
• ad27d9b: 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
• c67a7b0: 8269230: C2: main loop in micro benchmark never executed
• 962f1c1: 8262886: javadoc generates broken links with {@inheritdoc}
• f7ffd58: 8267602: [macos] [lanai] java/awt/PrintJob/Text/stringwidth.sh doesn't exit on cancelling print dialog
• 4930ae9: 8268592: JDK-8262891 causes an NPE in Lint.augment
• 9ac63a6: 8262841: Clarify the behavior of PhantomReference::refersTo
• aba6c55: 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp
• ... and 27 more: https://git.openjdk.java.net/jdk17/compare/d9cb068f4ba85e2be2ebc14e89e739b0a2d90409...master

Your commit was automatically rebased without conflicts.

[openjdk]

@jatin-bhateja Pushed as commit 4bbf11d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.