Skip to content
This repository has been archived by the owner. It is now read-only.

8278796: Incorrect behavior of FloatVector.withLane on X86 #28

Closed
wants to merge 2 commits into from

Conversation

jatin-bhateja
Copy link
Member

@jatin-bhateja jatin-bhateja commented Dec 15, 2021

  • Incorrect operand is being passed to insertps instruction which causes incorrectness issues in FloatVector.withLane operation.
  • Existing JTREG test cases have been modified appropriately with a non-zero insertion index.

Kindly review and share your comments.
Best Regards,
Jatin


Progress

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

Issue

  • JDK-8278796: Incorrect behavior of FloatVector.withLane on X86

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Dec 15, 2021

👋 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 openjdk bot added the rfr label Dec 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Dec 15, 2021

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

@openjdk openjdk bot added the hotspot-compiler label Dec 15, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 15, 2021

Webrevs

@sviswa7
Copy link

@sviswa7 sviswa7 commented Dec 15, 2021

@jatin-bhateja Thanks for fixing this issue. The patch looks good to me.

@openjdk
Copy link

@openjdk openjdk bot commented Dec 15, 2021

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

8278796: Incorrect behavior of FloatVector.withLane on X86

Reviewed-by: sviswanathan, kvn

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

  • be6b90d: 8278574: update --help-extra message to include default value of --finalization option
  • aec1b03: 8278389: SuspendibleThreadSet::_suspend_all should be volatile/atomic
  • e82310f: 8278575: update jcmd GC.finalizer_info to list finalization status
  • d3408a4: 8277964: ClassCastException with no stack trace is thrown with -Xcomp in method handle invocation
  • 69b5d49: 8272064: test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java needs update for JEP 416
  • d6b5544: 8278607: Misc issues in foreign API javadoc
  • 918e339: 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript
  • f48a3e8: 8278758: runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after JDK-8262134
  • 0cc989b: 8278744: KeyStore:getAttributes() not returning unmodifiable Set

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

@openjdk openjdk bot added the ready label Dec 15, 2021
Copy link

@vnkozlov vnkozlov left a comment

Looks fine to me too. I will run testing.

@jatin-bhateja please, update Description in bug report (it is empty now).

Copy link

@vnkozlov vnkozlov left a comment

Testing passed.

Copy link
Member

@PaulSandoz PaulSandoz left a comment

The changes to the tests look good, ideally we should test over all lane indexes, but i believe the insert intrinsic currently requires the lane index be a constant. Unsure if that is a restriction that can be lifted.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Dec 16, 2021

The changes to the tests look good, ideally we should test over all lane indexes, but i believe the insert intrinsic currently requires the lane index be a constant. Unsure if that is a restriction that can be lifted.

Hi @PaulSandoz , Your comments have been addressed.

@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented Dec 16, 2021

I think that is a little more robust, API-wise, but do i misunderstand the insert intrinsic with regards to requiring the lane index be a constant?

@sviswa7
Copy link

@sviswa7 sviswa7 commented Dec 16, 2021

@PaulSandoz The withLane implementation calls the withLaneHelper with constant index. e.g. please see Int128Vector withLane implementation has a switch statement to achieve this.

@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented Dec 16, 2021

@PaulSandoz The withLane implementation calls the withLaneHelper with constant index. e.g. please see Int128Vector withLane implementation has a switch statement to achieve this.

Oh yes, of course, thanks!

Copy link

@vnkozlov vnkozlov left a comment

I have to retest before update approval.

@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented Dec 16, 2021

Testing passed on latest commit.

Copy link

@vnkozlov vnkozlov left a comment

Good.

@jatin-bhateja
Copy link
Member Author

@jatin-bhateja jatin-bhateja commented Dec 17, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Dec 17, 2021

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

  • f5d7c77: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
  • be6b90d: 8278574: update --help-extra message to include default value of --finalization option
  • aec1b03: 8278389: SuspendibleThreadSet::_suspend_all should be volatile/atomic
  • e82310f: 8278575: update jcmd GC.finalizer_info to list finalization status
  • d3408a4: 8277964: ClassCastException with no stack trace is thrown with -Xcomp in method handle invocation
  • 69b5d49: 8272064: test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java needs update for JEP 416
  • d6b5544: 8278607: Misc issues in foreign API javadoc
  • 918e339: 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript
  • f48a3e8: 8278758: runtime/BootstrapMethod/BSMCalledTwice.java fails with release VMs after JDK-8262134
  • 0cc989b: 8278744: KeyStore:getAttributes() not returning unmodifiable Set

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated label Dec 17, 2021
@openjdk openjdk bot closed this Dec 17, 2021
@openjdk openjdk bot removed ready rfr labels Dec 17, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Dec 17, 2021

@jatin-bhateja Pushed as commit 8494fec.

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

theRealELiu added a commit to theRealELiu/jdk18 that referenced this issue Dec 20, 2021
…test fail

This bug appears intermittently and it's caused by vmaskAll_immI[1]
when the vector mask size is smaller than max predicate size of running
machine. It generates an all-true predicate without considering those
inactive bits. That may result in the wrong result of VectorMask.toLong.
The problematic code is as below:

```
        ShortVector.SPECIES_64.MaskAll(true).toLong()

assembly:

        ptrue   p0.h          <= MaskAll(true)
        mov     z16.h, p0/z, openjdk#1
        mov     z17.h, #0
        uzp1    z16.b, z16.b, z17.b
        fmov    x10, d16
        orr     x10, x10, x10, lsr openjdk#7
        orr     x10, x10, x10, lsr openjdk#14
        orr     x10, x10, x10, lsr openjdk#28
        and     x10, x10, #0xff

(gdb) p/x $p0 # on an SVE machine with vector length as 64 in bytes
$1 = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}

Expected:
(gdb) p/x $p0
$1 = {0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

```

Considering MaskAll is used in VectorMask.fromLong() only for a special
case and relies on the mechanism of inline and intrinsification, even it
could be optimized out, this patch also adds test cases for MaskAll to
reproduce this issue stably.

Also fix a small issue on register utilization for
sve_reduce_[max|min][D|F].

[1] https://github.com/openjdk/jdk18/blob/master/src/hotspot/cpu/aarch64/aarch64_sve.ad#L416

hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE enabled
system.

[INTERNAL ONLY]

hotspot/compiler/vectorapi, jdk/incubator/vector passed on a64fx.

TEST_LABEL: ent-arch-aarch64 && ent-conformance-enabled && ent-os-ubuntu
JDK_SCOPE: test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi

Jira: ENTLLT-4502
CustomizedGitHooks: yes
Change-Id: I401650c1cc32d730603a185d5ebf7bb263a4b539
theRealELiu added a commit to theRealELiu/jdk18 that referenced this issue Dec 20, 2021
…test fail

This bug appears intermittently and it's caused by vmaskAll_immI[1]
when the vector mask size is smaller than max predicate size of running
machine. It generates an all-true predicate without considering those
inactive bits. That may result in the wrong result of VectorMask.toLong.
The problematic code is as below:

```
        ShortVector.SPECIES_64.MaskAll(true).toLong()

assembly:

        ptrue   p0.h          <= MaskAll(true)
        mov     z16.h, p0/z, openjdk#1
        mov     z17.h, #0
        uzp1    z16.b, z16.b, z17.b
        fmov    x10, d16
        orr     x10, x10, x10, lsr openjdk#7
        orr     x10, x10, x10, lsr openjdk#14
        orr     x10, x10, x10, lsr openjdk#28
        and     x10, x10, #0xff

(gdb) p/x $p0 # on an SVE machine with vector length as 64 in bytes
$1 = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}

Expected:
(gdb) p/x $p0
$1 = {0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}

```

Considering MaskAll is used in VectorMask.fromLong() only for a special
case and relies on the mechanism of inline and intrinsification, even it
could be optimized out, this patch also adds test cases for MaskAll to
reproduce this issue stably.

Also fix a small issue on register utilization for
sve_reduce_[max|min][D|F].

[1] https://github.com/openjdk/jdk18/blob/master/src/hotspot/cpu/aarch64/aarch64_sve.ad#L416

hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE enabled
system.

Change-Id: I9631f26f9232ffe7a28b74f14062d945c32fa1fb
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
hotspot-compiler integrated
4 participants