RFR(XS):8216580:X86: Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic

[Deshpande, Vivek R]

Hi Vladimir

Would you please take a look at the patch. 
The Adjacent LoadS have different control RangeCheck node for accesses of type a[2i] and a[2i+1].
This patch allows those nodes to be isomorphic as they belong same counted loop and MulAddS2I nodes.
 
Webrev:
http://cr.openjdk.java.net/~vdeshpande/8216580/webrev.01/

Regards,
Vivek

-----Original Message-----
From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] 
Sent: Tuesday, January 15, 2019 2:57 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(XS):8216580:X86: Fix generation of VNNI vector code by allowing adjacent LoadS nodes to be isomorphic

Hi Vivek,

please add parentheses around the == comparison in lines 1225,1226.

Otherwise this looks reasonable to me but I'm not too familiar with that code.

Best regards,
Tobias

On 12.01.19 01:03, Deshpande, Vivek R wrote:
> Hi Tobias
> 
> The webrev for the bug JDK-821650 is here:
> http://cr.openjdk.java.net/~vdeshpande/8216580/webrev.00/
> This fixes 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.
> Could you please review it.
> 
> Regards,
> Vivek
> 
> -----Original Message-----
> From: Deshpande, Vivek R
> Sent: Friday, January 11, 2019 11:38 AM
> To: 'Tobias Hartmann' <tobias.hartmann at oracle.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 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
>