Omr: Prune vector IL opcodes

[0xdaryl]

In preparation for re-architecting the vector IL opcodes to support wider vector lengths and element types, I believe some cleanup is in order to help focus our design choices on only a core set of opcodes we really need.

At present, there are (at least) 109 vector IL opcodes. The vast majority of which are not used, documented, or tested, and have an incomplete implementation.

Based on my investigation, we should keep the following as a base set of opcodes that we can think about expanding to wider vector lengths. There are uses for these opcodes in OpenJ9. Some of these even have Tril tests written for them. As we get more into the vector redesign more may be proposed to be pruned from this list.

| IL Opcode |
| :---------- |
| vadd |
| vsub |
| vmul |
| vdiv |
| vneg |
| vand |
| vor |
| vxor |
| vnot |
| vsplats |
| v2v |
| vl2vd |
| vconst |
| vload |
| vloadi |
| vstore |
| vstorei |
| vcmpeq |
| vcmpne |
| vcmplt |
| vcmpgt |
| vcmple |
| vcmpge |
| getvelem |
| vsetelem |
| v[id]setelem |
| v[id]getelem |
| v[bsilfd]RegLoad |
| v[bsilfd]RegStore |
| vreturn | Z |
| vcall | Z |
| vcalli | Z |
| vperm | P |
| vdsqrt | P |
| vdsel | P |
| vbitselect | P,Z |
| vselect | |
| vdmergel | P |
| vdmergeh | P |
| vimergel | P |
| vimergeh | P |

The following IL opcodes may have some use when the vector opcodes are expanded to include different element sizes and may be worth keeping:

| IL Opcode | Implemented Platforms |
| :---------- | :-------------------: |
| vicmpeq | P |
| vicmpgt | P |
| vicmpge | P |
| vicmplt | P |
| vicmple | P |
| vdcmpeq | P |
| vdcmpne | P |
| vdcmpgt | P |
| vdcmpge | P |
| vdcmplt | P |
| vdcmple | P |
| vdmax | P |
| vdmin | P |
| vimin | P |
| vimax | P |

I recommend removing the following IL opcodes. As none of the list below has any known usage in OMR nor any known downstream projects I feel the justification to pardon any of these has to be strong enough to overcome eliminating the IL opcode now and re-introducing it later should the need arise. The advantage of introducing it again later is that it should come with proper justification, documentation, and Tril tests which are sorely lacking for all of these opcodes. Some of them could be reintroduced as intrinsics rather than opcodes.

| IL Opcode | Implemented Platforms |
| :---------- | :-------------------: |
| vicmpalleq | P |
| vicmpallne | P |
| vicmpallgt | P |
| vicmpallge | P |
| vicmpalllt | P |
| vicmpallle | P |
| vicmpanyeq | P |
| vicmpanyne | P |
| vicmpanygt | P |
| vicmpanyge | P |
| vicmpanylt | P |
| vicmpanyle | P |
| vdcmpalleq | P |
| vdcmpallne | P |
| vdcmpallgt | P |
| vdcmpallge | P |
| vdcmpalllt | P |
| vdcmpallle | P |
| vdcmpanyeq | P |
| vdcmpanyne | P |
| vdcmpanygt | P |
| vdcmpanyge | P |
| vdcmpanylt | P |
| vdcmpanyle | P |
| vucmplt | |
| vucmpgt | |
| vucmple | |
| vucmpge | |
| vinc | Z |
| vdec | Z |
| vcom | Z |
| vdmsub | P |
| vdmadd | P,Z |
| vdnmsub | P |
| vshl | Z |
| vushr | Z |
| vshr | Z |
| virem | P |
| vrem | Z |
| vdrem | P |
| vrand | Z |

[0xdaryl]

@gita-omr : I'd appreciate your input on this please.

[fjeremic]

@r30shah FYI as well.

[gita-omr]

@0xdaryl thanks a lot for doing the inventory of the vector opcodes. Are you planning to remove the evaluators for the opcodes in the last table? I am generally would be hesitant to remove any opcodes/evaluators until we have a good idea about the new model. Also, some of them might be useful for Vector API prototype and experimentation.

[0xdaryl]

I think if we agree to remove the opcodes, the evaluators should go with them. Mainly because there is no point in keeping one without the other. Implementation is always available in git history if we need to resurrect that code. The goal here is to simplify the overall picture from where we are now and start building vector IL from a core set of IL opcodes that are truly needed.

[IBMJimmyk]

getvelem looks to be a version of v[id]getelem that was extended to work with multiple data types. I think this applies to vsetelem and v[id]setelem. The final design will need to get rid of one or the other depending on how types will be handled.

Regarding figuring out the type of the vector node. For something like a vload it will be on the symref. For something like a vadd it is based on the children:
https://github.com/eclipse/omr/blob/ad78677f1c1279c9fc41e068322b9a5804d44b7d/compiler/il/OMRNode.cpp#L5240-L5257

Since vectors are currently assumed to be 128 bits in size, a datatype of VectorInt64 means 2 lanes of 64-bit ints. VectorInt32 means 4 lanes of 32-bit ints and so on.

[r30shah]

Looking into the the list of the suggested opcodes to clean-up, I can think of couple of opcodes that can be used with Vector API experimentation and probably can be used after words as well.

1. vdsqrt : We do have SQRT operation being introduced in Vector API that works with Floats and Double. This opcode can be used for that [1].
2. vselect : I think this opcode can be used to achieve BITWISE_BLEND operation of two vectors [2].
3. vperm : I think we can use this opcode for rearrange operation [3].

[1]. http://cr.openjdk.java.net/~kkharbas/vector-api/CSR/javadoc.02/jdk.incubator.vector/jdk/incubator/vector/DoubleVector.html#sqrt()
[2]. http://cr.openjdk.java.net/~kkharbas/vector-api/CSR/javadoc.02/jdk.incubator.vector/jdk/incubator/vector/VectorOperators.html#BITWISE_BLEND
[3]. http://cr.openjdk.java.net/~kkharbas/vector-api/CSR/javadoc.02/jdk.incubator.vector/jdk/incubator/vector/Vector.html#rearrange(jdk.incubator.vector.VectorShuffle)

[0xdaryl]

vcall, vcalli, and vreturn will be required on architectures that support returns in vector registers.