[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |bergner at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
This extra move is created by IRA:

Examining insn 22, def for 133
  all ok and transp
      Creating newreg=134 from oldreg=133
rescanning insn with uid = 22.
scanning new insn with uid = 25.
    New r134: setting preferred ALTIVEC_REGS, alternative VSX_REGS

Why?!

It was
(insn 22 11 20 2 (set (reg:V16QI 133)
        (vec_duplicate:V16QI (const_int 8 [0x8]))) "vec-rlmi-rlnm.c":45:10 1204
{xxspltib_v16qi}
     (nil))

and it is used only in

(insn 23 19 9 2 (set (reg:V2DI 127)
        (unspec:V2DI [
                (reg:V16QI 133)
            ] UNSPEC_VSX_SIGN_EXTEND)) "vec-rlmi-rlnm.c":45:10 1533
{vsx_sign_extend_qi_v2di}
     (expr_list:REG_DEAD (reg:V16QI 133)
        (expr_list:REG_EQUAL (const_vector:V2DI [
                    (const_int 8 [0x8]) repeated x2
                ])
            (nil))))

so copying it to another reg cannot help anything here?

Peter, can you take a look?

[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

--- Comment #2 from Peter Bergner <bergner at gcc dot gnu.org> ---
The copy us inserted by IRA's find_moveable_pseudos() function.  The problem
seems to be that the new pseudo r134 has a different preferred reg class than
the original pseudo r133. 

    r134: preferred VSX_REGS, alternative NO_REGS, allocno VSX_REGS
    a7 (r134,l0) best VSX_REGS, allocno VSX_REGS
    r133: preferred ALTIVEC_REGS, alternative VSX_REGS, allocno VSX_REGS

This leads to:

...
      Popping a7(r134,l0)  -- assign reg 32
      Popping a4(r127,l0)  -- assign reg 64
      Popping a6(r133,l0)  -- assign reg 64

So r134 is assigned the first VSX reg and r133 gets the first Altivec reg.

[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--- Comment #3 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Moving to P4.  This is not important, and we will fix this in GCC 11.

[Bug target/91804] [10/11 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.0                        |10.2

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.1 has been released.

[Bug target/91804] [10/11 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.2                        |10.3

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.2 is released, adjusting target milestone.

[Bug target/91804] [10/11 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug target/91804] [10/11/12/13 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug target/91804] [10/11/12/13/14 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[aagarwa at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Ajit Kumar Agarwal <aagarwa at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aagarwa at gcc dot gnu.org

--- Comment #8 from Ajit Kumar Agarwal <aagarwa at gcc dot gnu.org> ---
I don't see extra xxlor with latest gcc trunk. I think this is fixed.
I think we should close this PR.

Thanks & Regards
Ajit

[Bug target/91804] [10/11/12/13/14 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91804

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pthaugen at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Ajit Kumar Agarwal from comment #8)
> I don't see extra xxlor with latest gcc trunk. I think this is fixed.
> I think we should close this PR.

Thanks for looking Ajit.  I did a git bisect and it flagged a patch from Pat as
fixing this:

commit 51d89e61f7ebfe75ca752e62bd29b58cb957235c
Author:     Pat Haugen <pthaugen@linux.ibm.com>
AuthorDate: Mon May 10 13:49:06 2021 -0500
Commit:     Pat Haugen <pthaugen@linux.ibm.com>
CommitDate: Mon May 10 13:49:06 2021 -0500

    Add ALTIVEC_REGS as pressure class.

    Code that has heavy register pressure on Altivec registers can suffer from
    over-aggressive scheduling during sched1, which then leads to increased
    register spill. This is due to the fact that registers that prefer
    ALTIVEC_REGS are currently assigned an allocno class of VSX_REGS. This then
    misleads the scheduler to think there are 64 regs available, when in
reality
    there are only 32 Altivec regs. This patch fixes the problem by assigning
an
    allocno class of ALTIVEC_REGS and adding ALTIVEC_REGS as a pressure class.

    2021-05-10  Pat Haugen  <pthaugen@linux.ibm.com>

    gcc/ChangeLog:

            * config/rs6000/rs6000.c (rs6000_ira_change_pseudo_allocno_class):
            Return ALTIVEC_REGS if that is best_class.
            (rs6000_compute_pressure_classes): Add ALTIVEC_REGS.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/fold-vec-insert-float-p9.c: Adjust counts.
            * gcc.target/powerpc/vec-rlmi-rlnm.c: Likewise.