[14] RFR (L): 8234391: C2: Generic vector operands

[Viswanathan, Sandhya]

Could we please get one more review of this patch?

Best Regards,
Sandhya


-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
Sent: Tuesday, November 19, 2019 6:31 AM
To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Bhateja, Jatin <jatin.bhateja at intel.com>; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
Subject: [14] RFR (L): 8234391: C2: Generic vector operands

http://cr.openjdk.java.net/~vlivanov/jbhateja/8234391/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8234391

Introduce generic vector operands and migrate existing usages from fixed sized operands (vec[SDXYZ]) to generic ones.

(It's an updated version of generic vector support posted for review in August, 2019 [1] [2]. AD instruction merges will be handled separately.)

On a high-level it is organized as follows:

   (1) all AD instructions in x86.ad/x86_64.ad/x86_32.ad use vec/legVec;

   (2) at runtime, right after matching is over, a special pass is performed which does:

       * replaces vecOper with vec[SDXYZ] depending on mach node type
          - vector mach nodes capute bottom_type() of their ideal prototype;

       * eliminates redundant reg-to-reg vector moves (MoveVec2Leg
/MoveLeg2Vec)
          - matcher needs them, but they are useless for register allocator (moreover, may cause additional spills);


    (3) after post-selection pass is over, all mach nodes should have fixed-size vector operands.


Some details:

    (1) vec and legVec are marked as "dynamic" operands, so 
post-selection rewriting works


    (2) new logic is guarded by new matcher flag 
(Matcher::supports_generic_vector_operands) which is enabled only on x86


    (3) post-selection analysis is implemented as a single pass over the 
graph and processing individual nodes using their own (for DEF operands) 
or their inputs (USE operands) bottom_type() (which is an instance of 
TypeVect)


    (4) most of the analysis is cross-platform and interface with 
platform-specific code through 3 methods:

      static bool is_generic_reg2reg_move(MachNode* m);
      // distinguishes MoveVec2Leg/MoveLeg2Vec nodes

      static bool is_generic_vector(MachOper* opnd);
      // distinguishes vec/legVec operands

      static MachOper* clone_generic_vector_operand(MachOper* 
generic_opnd, uint ideal_reg);
      // constructs fixed-sized vector operand based on ideal reg
      //   vec    + Op_Vec[SDXYZ] =>    vec[SDXYZ]
      //   legVec + Op_Vec[SDXYZ] => legVec[SDXYZ]


    (5) TEMP operands are handled specially:
      - TEMP uses max_vector_size() to determine what fixed-sized 
operand to use
          * it is needed to cover reductions which don't produce vectors 
but scalars
      - TEMP_DEF inherits fixed-sized operand type from DEF;


    (6) there is limited number of special cases for mach nodes in 
Matcher::get_vector_operand_helper:

        - RShiftCntV/RShiftCntV: though it reports wide vector type as 
Node::bottom_type(), its ideal_reg is VecS! But for vector nodes only 
Node::bottom_type() is captured during matching and not ideal_reg().

        - vshiftcntimm: chain instructions which convert scalar to 
vector don't have vector type.


    (7) idealreg2regmask initialization logic is adjusted to handle 
generic vector operands (see Matcher::get_vector_regmask)


    (8) operand renaming in x86_32.ad & x86_64.ad to avoid name 
conflicts with new vec/legVec operands


    (9) x86_64.ad: all TEMP usages of vecS/legVecS are replaced with 
regD/legRegD
       - it aligns the code between x86_64.ad and x86_32.ad
       - strictly speaking, it's illegal to use vector operands on a 
non-vector node (e.g., string_inflate) unless its usage is guarded by C2 
vector support checks (-XX:MaxVectorSize=0)


Contributed-by: Jatin Bhateja <jatin.bhateja at intel.com>
Reviewed-by: vlivanov, sviswanathan, ?

Testing: tier1-tier4, jtreg compiler tests on KNL and SKL,
          performance testing (SPEC* + Octane + micros / G1 + ParGC).

Best regards,
Vladimir Ivanov

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-August/034822.html

[2] 
http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf