8288467: remove memory_operand assert for spilled instructions #33

eme64 · 2022-06-17T09:32:40Z

In JDK-8282555 I added this assert, because on x64 this seems to always hold. But it turns out there are instructions on x86 (32bit) that violate this assumption.

Why it holds on x64
It seems we only ever do one read or one write per instruction. Instructions with multiple memory operands are extremely rare.

we spill from register to memory: we land in the if case, where the cisc node has an additional input slot for the memory edge.
we spill from register to stackSlot: no additional input slot is reserved, we land in else case and add an additional precedence edge.

Why it is violated on x86 (32bit)
We have additional cases that land in the else case. For example spilling src1 from addFPR24_reg_mem to addFPR24_mem_cisc.

jdk19/src/hotspot/cpu/x86/x86_32.ad

Lines 10325 to 10327 in 53bf1bf

    
           instruct addFPR24_reg_mem(stackSlotF dst, regFPR src1, memory src2) %{ 
        
             predicate(UseSSE==0 && Compile::current()->select_24_bit_instr()); 
        
             match(Set dst (AddF src1 (LoadF src2)));

jdk19/src/hotspot/cpu/x86/x86_32.ad

Lines 10368 to 10370 in 53bf1bf

    
           instruct addFPR24_mem_cisc(stackSlotF dst, memory src1, memory src2) %{ 
        
             predicate(UseSSE==0 && Compile::current()->select_24_bit_instr()); 
        
             match(Set dst (AddF src1 (LoadF src2)));

We land in the else case, because both have 2 inputs, thus oper_input_base() == 2.
And both have memory operands, so the assert must fail.

Solutions

Remove the Assert, as it is incorrect.
Extend the assert to be correct.
- case 1: reg to mem spill, where we have a reserved input slot in cisc for memory edge
- case 2: reg to stackSlot spill, where both mach and cisc have no memory operand.
- other cases, with various register, stackSlot and memory inputs and outputs. We would have to find a general rule, and test it properly, which is not trivial because getting registers to spill is not easy to precisely provoke.
Have platform dependent asserts. But also this makes testing harder.

For now I went with 1. as it is simple and as far as I can see correct.

Running tests on x64 (should not fail). I need someone to help me with testing x86 (32bit). I only verified the reported test failure with a 32bit build.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8288467: remove memory_operand assert for spilled instructions

Reviewers

Tobias Hartmann (@TobiHartmann - Reviewer) ⚠️ Review applies to d082aa91
Aleksey Shipilev (@shipilev - Reviewer)
Jatin Bhateja (@jatin-bhateja - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk19 pull/33/head:pull/33
$ git checkout pull/33

Update a local copy of the PR:
$ git checkout pull/33
$ git pull https://git.openjdk.org/jdk19 pull/33/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 33

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk19/pull/33.diff

…ory operand, only stack

bridgekeeper · 2022-06-17T09:33:17Z

👋 Welcome back epeter! 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 · 2022-06-17T09:44:32Z

@eme64 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.

mlbridge · 2022-06-17T09:48:51Z

Webrevs

01: Full - Incremental (951e91de)
00: Full (d082aa91)

TobiHartmann

Looks reasonable to me. It would be good if @jatin-bhateja could also have a look.

src/hotspot/share/opto/chaitin.cpp

openjdk · 2022-06-20T07:58:10Z

@eme64 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:

8288467: remove memory_operand assert for spilled instructions

Reviewed-by: thartmann, shade, jbhateja

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 11 new commits pushed to the master branch:

b9c3966: 8288671: Problematic fix for font boosting
453e8be: 8288527: broken link in java.base/java/util/zip/package-summary.html
33d0363: 8288741: JFR: Change package name of snippet files
0408f9c: 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
1cf83a4: 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
09da87c: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
ed714af: 8288564: C2: LShiftLNode::Ideal produces wrong result after JDK-8278114
ae030bc: 8288397: AArch64: Fix register issues in SVE backend match rules
f12d044: 8288692: jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java fails after JDK-8288545
97544be: 8268398: 15% increase in JFR footprint in Noop-Base
... and 1 more: https://git.openjdk.org/jdk19/compare/53bf1bfdabb79b37afedd09051d057f9eea620f2...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.

fix typo Co-authored-by: Tobias Hartmann <tobias.hartmann@oracle.com>

shipilev

Linux x86_32 fastdebug tier1 and tier2 pass.

jatin-bhateja · 2022-06-21T15:15:51Z

Hi @eme64,
Thanks for pointing this out. Original bug was related to incorrect scheduling of CISC node with just the stack operand which was circumvented by adding a precedence edge from incoming spill copy node. In general there is always a 1-1 correspondence b/w memory_operand index of CISC instruction and cisc_operand index of non-CISC counterpart.

As you mentioned there are not many cases where an instruction accept more than one memory operand.

Following patterns in x86_32.ad (which are relevant to SSE targets) are the only occurrences accepting more than one memory operand.

instruct addFPR24_mem_cisc(stackSlotF dst, memory src1, memory src2) %{
instruct addFPR24_mem_mem(stackSlotF dst, memory src1, memory src2) %{
instruct mulFPR24_mem_mem(stackSlotF dst, memory src1, memory src2) %{

And for each of these a constant -1 value is returned as memory_operand currently.

const MachOper* addFPR24_mem_ciscNode::memory_operand() const { return (MachOper*)-1; }
const MachOper* addFPR24_mem_cisc_0Node::memory_operand() const { return (MachOper*)-1; }
const MachOper* addFPR24_mem_memNode::memory_operand() const { return (MachOper*)-1; }
const MachOper* mulFPR24_mem_memNode::memory_operand() const { return (MachOper*)-1; }

Post matcher operand array is sacrosanct, only problem here is that oper_input_base() for non-cisc counterparts are 2 since first input is memory edge. Due to this it enters the control flow having assertion check.

Your fix to remove assertion, looks safe to me.

Best Regards,
Jatin

eme64 · 2022-06-21T15:19:58Z

Thanks @jatin-bhateja @shipilev @TobiHartmann for your reviews, and help with clarifying, verifying and even testing.
/integrate

openjdk · 2022-06-21T15:22:12Z

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

b9c3966: 8288671: Problematic fix for font boosting
453e8be: 8288527: broken link in java.base/java/util/zip/package-summary.html
33d0363: 8288741: JFR: Change package name of snippet files
0408f9c: 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
1cf83a4: 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
09da87c: 8288485: jni/nullCaller/NullCallerTest.java failing (ppc64)
ed714af: 8288564: C2: LShiftLNode::Ideal produces wrong result after JDK-8278114
ae030bc: 8288397: AArch64: Fix register issues in SVE backend match rules
f12d044: 8288692: jdk/javadoc/doclet/testTagMisuse/TestTagMisuse.java fails after JDK-8288545
97544be: 8268398: 15% increase in JFR footprint in Noop-Base
... and 1 more: https://git.openjdk.org/jdk19/compare/53bf1bfdabb79b37afedd09051d057f9eea620f2...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-06-21T15:22:28Z

@eme64 Pushed as commit af05139.

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

8288467: C2: assert(cisc->memory_operand() == nullptr) failed: no mem…

d082aa9

…ory operand, only stack

openjdk bot added the rfr Pull request is ready for review label Jun 17, 2022

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Jun 17, 2022

eme64 changed the title ~~8288467: C2: assert(cisc->memory_operand() == nullptr) failed: no memory operand, only stack~~ 8288467: remove memory_operand assert for spilled instructions Jun 17, 2022

TobiHartmann approved these changes Jun 20, 2022

View reviewed changes

src/hotspot/share/opto/chaitin.cpp Outdated Show resolved Hide resolved

openjdk bot added the ready Pull request is ready to be integrated label Jun 20, 2022

Update src/hotspot/share/opto/chaitin.cpp

951e91d

fix typo Co-authored-by: Tobias Hartmann <tobias.hartmann@oracle.com>

shipilev approved these changes Jun 20, 2022

View reviewed changes

jatin-bhateja approved these changes Jun 21, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jun 21, 2022

openjdk bot closed this Jun 21, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 21, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

8288467: remove memory_operand assert for spilled instructions #33

8288467: remove memory_operand assert for spilled instructions #33

Uh oh!

eme64 commented Jun 17, 2022 •

edited by openjdk bot

Loading

Uh oh!

bridgekeeper bot commented Jun 17, 2022

Uh oh!

openjdk bot commented Jun 17, 2022

Uh oh!

mlbridge bot commented Jun 17, 2022 •

edited

Loading

Uh oh!

TobiHartmann left a comment

Uh oh!

Uh oh!

openjdk bot commented Jun 20, 2022 •

edited

Loading

Uh oh!

shipilev left a comment

Uh oh!

jatin-bhateja commented Jun 21, 2022

Uh oh!

eme64 commented Jun 21, 2022

Uh oh!

openjdk bot commented Jun 21, 2022

Uh oh!

openjdk bot commented Jun 21, 2022

Uh oh!

Uh oh!

	instruct addFPR24_reg_mem(stackSlotF dst, regFPR src1, memory src2) %{
	predicate(UseSSE==0 && Compile::current()->select_24_bit_instr());
	match(Set dst (AddF src1 (LoadF src2)));

8288467: remove memory_operand assert for spilled instructions #33

8288467: remove memory_operand assert for spilled instructions #33

Uh oh!

Conversation

eme64 commented Jun 17, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jun 17, 2022

Uh oh!

openjdk bot commented Jun 17, 2022

Uh oh!

mlbridge bot commented Jun 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

TobiHartmann left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

openjdk bot commented Jun 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shipilev left a comment

Choose a reason for hiding this comment

Uh oh!

jatin-bhateja commented Jun 21, 2022

Uh oh!

eme64 commented Jun 21, 2022

Uh oh!

openjdk bot commented Jun 21, 2022

Uh oh!

openjdk bot commented Jun 21, 2022

Uh oh!

Uh oh!

eme64 commented Jun 17, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Jun 17, 2022 •

edited

Loading

openjdk bot commented Jun 20, 2022 •

edited

Loading