Handle new vector opcodes

[gita-omr]

Depends on eclipse-omr/omr#6942

[gita-omr]

Added commit to handle compressExpandOp() intrinsic.

[Akira1Saitoh]

It seems that we need to recognize VectorSupport.broadcastInt to vectorize lanewise shift operations with immediate shift amount.
https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/e336ea0f0702e0a790ad0f52658b093fc1a86b8a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java#L1008-L1020

[gita-omr]

It seems that we need to recognize VectorSupport.broadcastInt to vectorize lanewise shift operations with immediate shift amount. https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/e336ea0f0702e0a790ad0f52658b093fc1a86b8a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java#L1008-L1020

Thanks! Trying to figure out how it's different from fromBitsCoerced intrinsic for which we generate vsplats.

[gita-omr]

fromBitsCoerced takes long for all types and that long is a bit pattern that needs to be converted to each type. broadcastInt is for non-FP types only and takes int as a parameter. We will generate vsplats for it as well, just without conversion.

[gita-omr]

Actually, broadcastInt seems to be doing a shift by the same constant of each vector element (unary operation). @BradleyWood @Akira1Saitoh do you think it's better to have a new opcode (something like vshrConst) or convert it into vsplats of the constant and then vshr (for example) ?

[Akira1Saitoh]

@gita-omr Either way works for AArch64. I have already drafted vector shift evaluators with the assumption that vsplats of the constant comes as the second child of vector shift node for broadcastInt case.
Akira1Saitoh/omr@c0a7e2f
AArch64 has dedicated instructions for vector shifts with immediate value as well as vector shifts with the value in the register.
https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SHL--Shift-Left--immediate--
https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--

[gita-omr]

@gita-omr Either way works for AArch64. I have already drafted vector shift evaluators with the assumption that vsplats of the constant comes as the second child of vector shift node for broadcastInt case.

Thanks @Akira1Saitoh ! What if vsplats is put in a register, for example by PRE. Then, we will not be able to use vector shift with immediate instruction.

[Akira1Saitoh]

@gita-omr Agree. If we have dedicated opcodes, the evaluator will be able to use appropriate instructions without getting affected by other optimizations.

[Akira1Saitoh]

@gita-omr Looks like the same applies to rotate operations.

It seems that we need to recognize VectorSupport.broadcastInt to vectorize lanewise shift operations with immediate shift amount. https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/e336ea0f0702e0a790ad0f52658b093fc1a86b8a/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java#L1008-L1020

[gita-omr]

@gita-omr Looks like the same applies to rotate operations

Thanks @Akira1Saitoh . I will add those too.

[0xdaryl]

Is this a breaking dependence on the OMR PR, or does the OMR one simply have to merge first?

[gita-omr]

Is this a breaking dependence on the OMR PR, or does the OMR one simply have to merge first?

OMR just needs to be merged first.

[gita-omr]

Addressed comments above.

[knn-k]

Jenkins test sanity all jdk17 depends eclipse-omr/omr#6942

[knn-k]

Waiting for eclipse-omr/omr#6942 to be merged.

[0xdaryl]

Waiting for eclipse-omr/omr#6942 to be merged.

Because 6942 is needed for an OpenJ9 feature, I am holding off merging it until the OMR Acceptance build is successful. Even though the risk is low, I don't want to inject any unnecessary instability into that build because it has been nearly 2 weeks since the last promotion.

[knn-k]

Jenkins compile amac jdk17