On Wed, Aug 26, 2026 at 02:44:58PM -0500, Vijay Shankar wrote:
> Hello,
>
> Changes form v2:
> * Removed AIX related changes
> * update test case to check pattern directly
>
> Changes form v1:
> * Cleaned up naming in rs6000.md
> * Cleaned up guards to be on same line.
> * Test case use \m...\M instead of relying on space
>
> Thank you,
> Vijay.
>
> POWER10 has instruction fusion for addis+addi pairs. However,
> the scheduler was breaking these pairs apart to optimize for
> dependency chains, losing the fusion benefit.
>
> This patch implements "fake" instructions that represent both
> instructions as a single pattern. This prevents the scheduler from
> reordering them while still generating the correct two-instruction
> sequence.
>
> Existing high/low patterns are guarded to
> prevent conflicts with the new fusion patterns.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
> Bootstrapped and tested on powerpc64-linux-gnu with no regressions.
>
> 2026-03-16 Vijay Shankar <[email protected]>
>
> gcc/ChangeLog:
> PR target/108018
> * config/rs6000/rs6000.md (*largetoc_high): Add guards.
> (*largetoc_high_plus): Likewise.
> (*largetoc_low): Likewise.
> (*largetocp10): New define_insn.
> (*largetocp10_plus): Likewise.
> (*tocref<mode>): Add guards.
>
> gcc/testsuite/ChangeLog:
> PR target/108018
> * gcc.target/powerpc/pr108018.c: New test.
Please rewrite the patch to use TARGET_P10_FUSION and not using tests like:
rs6000_tune != PROCESSOR_POWER10
The reason is we might add future processors that have other modes. It
may be that some other processors will also having tuning similar to
the power10, and other processors won't. Using the already existing
TARGET_P10_FUSION means we can control this in one location, rather
than going through the code.
This is similar to the TARGET_P8_FUSION where p8 processors had
specific tunings that p9, p10, p11, etc. do not.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: [email protected]
