8230015: [instruction selector] generic vector operands support.

Bhateja, Jatin jatin.bhateja at intel.com
Wed Aug 28 09:44:35 UTC 2019


Hi Yang,

Thanks for your response.

We are also working over the idea of moving out the operator (uOp and bOp) into a separate ideal node, but that will need changes in shape of ideal graph. 

Generic operands is another level of optimization which will complement "aggressive optimization". 
In addition, it will also reduce the number of checks for different vector operand type (vecS, vecD, vecX, vecY, vecZ and their legacy variants) within 
ADLC generate DFA used while matching,  since there will only be two vector operands (vecG and legVecG) now.

Current patch enables this support only for x86 target, to get a feedback from community. 

Best Regards,
Jatin 


> -----Original Message-----
> From: Yang Zhang (Arm Technology China) <Yang.Zhang at arm.com>
> Sent: Wednesday, August 28, 2019 2:49 PM
> To: Bhateja, Jatin <jatin.bhateja at intel.com>; hotspot-compiler-
> dev at openjdk.java.net
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Subject: RE: 8230015: [instruction selector] generic vector operands support.
> 
> Hi Jatin
> 
> The question how to reduce code size is discussed previously. I also create a
> JBS to track it under panama project.
> https://bugs.openjdk.java.net/browse/JDK-8229866
> There is a more aggressive idea.
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> April/033362.html
> 
> Using the idea of generic vector operands, I implement an example
> (vaddB/S/I) in AArch64 platform. The code size reduction in libjvm.so is
> ~30kb. If all the vector instructions are merged, the estimated size reduction
> will be ~300kb.
> 
> How about using a more aggressive way to reduce code size?
> 
> PS. When I test this patch in AArch64 platform, build fails with the log
> undefined reference to `Matcher::do_post_selection_processing(Compile*,
> Node*)'.
> I fix this failure by adding #ifdef X86 to these code.
> 
> Regards
> Yang
> 
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Bhateja, Jatin
> Sent: Thursday, August 22, 2019 2:50 PM
> To: hotspot-compiler-dev at openjdk.java.net
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Subject: 8230015: [instruction selector] generic vector operands support.
> 
> Hi All,
> 
> Please find below a patch for generic vector operands[1] support during
> instruction selection.
> 
> Motivation behind the patch is to reduce the number of vector selection
> patterns whose operands meagerly differ in vector lengths.
> This will not only result in lesser code being generated by ADLC which
> effectively translates to size reduction in libjvm.so but also help in better
> maintenance of AD files.
> 
> Using generic operands we were able to collapse multiple vector patterns
> over mainline
>              Initial number of vector instruction patterns (vec[XYZSD] +
> legVec[ZXYSD]   :  510
>              Reduced vector instruction patterns  (vecG + legVecG)
> :  222
> 
> With this we could see around 1MB size reduction in libjvm.so.
> 
> In order to have minimal impact over downstream compiler passes, a post-
> selection pass has been introduced (currently enabled only for X86 target)
> which replaces these generic operands with their corresponding concreter
> vector length variants.
> 
> JBS      : https://bugs.openjdk.java.net/browse/JDK-8230015
> Patch  :
> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin Bhateja
> 
> [1]
> http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_opera
> nds_support_v1.0.pdf
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.


More information about the hotspot-compiler-dev mailing list