RFR(S):8216050:X86: Fix for Superword optimization fails with assert(0 <= i && i < _len) failed: illegal index

[Deshpande, Vivek R]

Hi Tobias

Thanks for reviewing the patch.
I have made the changes according to your suggestion.
In this webrev: http://cr.openjdk.java.net/~vdeshpande/8216050/webrev.01/
I have fix for the crash reported in the 8216050.

The lower cost is needed for generation of vpdpwssd instruction, by combining AddVI and MulAddVS2VI.
For other instructions pmaddwd and vpmaddwd, they get generated on platforms upto skylake with default cost.

I have updated the bug also with the link to webrev.

I have created a different bug JDK-8216580 for  
 3) Fix generation of vector code by allowing adjacent LoadS nodes to be isomorphic when they have different control RangeCheck nodes
     for a[i] and a[i+1] accesses in same MulAddS2I node

Thank you.
Regards,
Vivek

-----Original Message-----
From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] 
Sent: Friday, January 11, 2019 4:49 AM
To: Deshpande, Vivek R <vivek.r.deshpande at intel.com>; hotspot-compiler-dev at openjdk.java.net compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Raj, Guru <guru.raj at intel.com>
Subject: Re: RFR(S):8216050:X86: Fix for Superword optimization fails with assert(0 <= i && i < _len) failed: illegal index

Hi Vivek,

On 11.01.19 07:58, Deshpande, Vivek R wrote:
> 1) Fix for the crash by matching the operand by swapping to right positions. 

Looks good but the change to loopopts.cpp:530 screwed up the indentation around the ifs, please fix.

> 2) Cost based generation of vpdpwssd instruction. 

Other instructions added by JDK-8214751 still miss a cost definition, for example:
http://hg.openjdk.java.net/jdk/jdk/rev/4bb6e0871bf7#l5.20

> 3) Fix generation of vector code by allowing adjacent LoadS nodes to 
> be isomorphic when they have different control RangeCheck nodes
>     for a[i] and a[i+1] accesses in same MulAddS2I node

This is unrelated to the original bug, right? If so, this should be integrated with a separate RFE.

Thanks,
Tobias