[JDK-8353240] VectorRearrangeTest failures with 64-bit-element 128-bit vectors

[graalvmbot]

Hi,

This one is nasty. For some inexplicable reasons, vpermilpd uses the second bit to find which element from the source vector is chosen at each element of the index vector. That is it does dst[i] = src[idx[i] >> 1]. To make matters worse, Intel sdm says that:

The control bits are located at bit 0 of each quadword element (see Figure 5-24). Each control determines which of the source element in an input pair is selected for the destination element. Each pair of source elements must lie in the same 128-bit region as the destination

Which is wrong, the control bits are located at bit 1 of each quadword element.

Come back to the Mach 5 test, it looks like this:

public void rearrange_long128() {
    VectorShuffle<Long> shuffle = VectorShuffle.fromArray(lspec128, indexes[0], 0);
    for (int i = 0; i < LENGTH; i += lspec128.length()) {
        LongVector.fromArray(lspec128, lsrc, i)
                  .rearrange(shuffle)
                  .intoArray(ldst, i);
    }
}

So why it only fails with DeoptimizeALot? It is because Graal does not vectorize the graph if any VectorAPINode is not intrinsifiable. In this case, the normal compilation does not vectorize because VectorShuffle::fromArray is not intrinsifiable. However, when the method deoptimize, because the method is still running, the VM tries to make an OSR compilation starting at the loop head. This vectorizes because the non-intrinfiable VectorShuffle::fromArray is out of the scope of the OSR compilation.

I fix the implementation, it is hard to believe x86 does not have an equivalent of vpermq and vpermpd for 128-bit vectors. We have to shift the index vector left by 1 to perform vpermilpd.

Please take a look and leave your reviews, thanks a lot.