https://gcc.gnu.org/g:f040338dcb2d8221b87ecdb45c2fcaeb7926fb84

commit f040338dcb2d8221b87ecdb45c2fcaeb7926fb84
Author: Michael Meissner <[email protected]>
Date:   Thu Jun 25 15:33:48 2026 -0400

    PR target/117251: Improve vector fusion #1
    
    See the following post for a complete explanation of what the patches
    for PR target/117251:
    
     * https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686474.html
    
    This is patch #1 of 45 to generate the 'XXEVAL' instruction on power10
    and power11 instead of using the Altivec 'VAND' instruction feeding
    into 'VAND'.  The 'XXEVAL' instruction can use all 64 vector registers,
    instead of the 32 registers that traditional Altivec vector
    instructions use.  By allowing all of the vector registers to be used,
    it reduces the amount of spilling that a large benchmark generated.
    
    Currently the following code:
    
            vector int a, b, c, d;
            a = (c & d) & b;
    
    Generates:
    
            vand   t,c,d
            vand   a,t,b
    
    Now in addition with this patch, if the arguments or result is
    allocated to a traditional FPR register, the GCC compiler will now
    generate the following code instead of adding vector move instructions:
    
            xxeval a,b,c,1
    
    Since fusion using 2 Altivec instructions is slightly faster than using
    the 'XXEVAL' instruction we prefer to generate the Altivec instructions
    if we can.  In addition, because 'XXEVAL' is a prefixed instruction, it
    possibly might generate an extra NOP instruction to align the 'XXEVAL'
    instruction.
    
    I have tested these patches on both big endian and little endian
    PowerPC servers, with no regressions.  Can I check these patchs into
    the trunk?
    
    2026-06-25  Michael Meissner  <[email protected]>
    
    gcc/
    
            PR target/117251
            * config/rs6000/fusion.md: Regenerate.
            * config/rs6000/genfusion.pl (gen_logical_addsubf): Add
            support to generate vector/vector and/and fusion if XXEVAL is
            supported.
            * config/rs6000/predicates.md (vector_fusion_operand): New
            predicate.
            * config/rs6000/rs6000.md (isa attribute): Add p10p.
            (enabled attribute): Add support for XXEVAL support.
            * config/rs6000/rs6000.h (TARGET_XXEVAL): New macro.

Diff:
---
 gcc/config/rs6000/predicates.md | 12 ++++++++++++
 gcc/config/rs6000/rs6000.h      |  4 ++++
 2 files changed, 16 insertions(+)

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 0df872529de0..41e150fb2a80 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -119,6 +119,18 @@
   return VSX_REGNO_P (REGNO (op));
 })
 
+;; Return 1 if op is a register that can be used for vector fusion.  If XXEVAL
+;; is supported, return true for all VSX registers, otherwise the fusion is
+;; limited to Altivec registers since the machine only fuses Altivec
+;; operations.
+(define_predicate "vector_fusion_operand"
+  (match_operand 0 "register_operand")
+{
+  return (TARGET_XXEVAL
+         ? vsx_register_operand (op, mode)
+         : altivec_register_operand (op, mode));
+})
+
 ;; Return 1 if op is a vector register that operates on floating point vectors
 ;; (either altivec or VSX).
 (define_predicate "vfloat_operand"
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index f145c0fb54db..8fe848b48f1a 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -526,6 +526,10 @@ extern int rs6000_vector_align[];
 #define TARGET_MMA_DENSE_MATH          (TARGET_MMA && TARGET_DENSE_MATH)
 #define TARGET_MMA_NO_DENSE_MATH       (TARGET_MMA && !TARGET_DENSE_MATH)
 
+/* Enable XXEVAL support if we support prefixed instructions and at least
+   power10.  */
+#define TARGET_XXEVAL  (TARGET_POWER10 && TARGET_PREFIXED)
+
 /* In switching from using target_flags to using rs6000_isa_flags, the options
    machinery creates OPTION_MASK_<xxx> instead of MASK_<xxx>.  The MASK_<xxxx>
    options that have not yet been replaced by their OPTION_MASK_<xxx>

Reply via email to