8257531: Super word not applied to a loop of simple Buffer operations #1618
Conversation
|
Webrevs
|
Looks good to me. |
@vnkozlov This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
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 22 new commits pushed to the
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.
|
Java test looks good. |
Thank you @PaulSandoz and @rwestrel for reviews. |
/integrate |
@vnkozlov Since your change was applied there have been 22 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit dd0b945. |
In Buffer case there is additional (loop invariant) load from java/nio/IntBuffer.offset field.
SuperWord did not handle loop's invariants in complex address expressions (only when vectorization is forced):
AddP(addr, AddP(addr, addr, LShiftL(ConvI2L(CastII(AddI(AddI(iv_phi, invariant_LoadI), incr))), shift)), 16)
Invariant reference is used to make sure all memory accesses in vectors use the same one. And only when alignment code is generated in pre-loop it is used for code generatin. But that code did not take into account that invariant have to be scaled if needed as in this example (invariant_LoadI << shift).
I propose to record scaling (left shift) for invariant when it is present and use it to compare invariants and in pre-loop alignment code generation. I also slightly modified tracing output code for invariants.
This allow vectorize Java code which uses Buffer.
I added new test based on @PaulSandoz example. It tests presence of new vectors and correctness of vectorized code.
I included case (ByteBuffer.allocateDirect()) which is not vectorized because it uses Unsafe access - SuperWord complains about CastX2P(AddL) nodes which it sees instead of AddP. We may consider vectorizing such code too later.
Testing: tier1-4, precheckin-comp (-Xcomp), renaissance test
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1618/head:pull/1618
$ git checkout pull/1618