[Bug rtl-optimization/107762] New: [13 Regression] Recent change causing regressions on s390-linux-gnu

[Bug rtl-optimization/107762] New: [13 Regression] Recent change causing regressions on s390-linux-gnu

[law at gcc dot gnu.org]

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

            Bug ID: 107762
           Summary: [13 Regression] Recent change causing regressions on
                    s390-linux-gnu
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
                CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
            Target: s390-linux-gnu

This change:

commit 3e2bdf2460a34a2389dee813a2ba8ecf976f2ec9
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Fri Nov 4 11:15:57 2022 +0100

    Do not use subword paradoxical subregs in emit_group_store

    The goal of the trick is to make life easier for the combiner, but subword
    paradoxical subregs make it harder for the register allocator instead.

    gcc/
            * expr.cc (emit_group_store): Do not use subword paradoxical
subregs

Is causing at least two regressions on s390-linux-gnu:
Tests that now fail, but worked before (19 tests):
[ ... ]
gcc.target/s390/arch12/mul-1.c scan-assembler-times \tmsgrkc\t 1
gcc.target/s390/arch13/sel-1.c scan-assembler-times \tselgr(?:h|le)\t 1
[ ... ]

Those are the only two that I have positively confirmed are due to the
emit_group_store change.

I looked briefly at the resulting assembly code for the mul-1 test and it looks
worse to me after that change.  But I'm far from an s390 expert.

You can see this with a cross compiler, you don't need a full toolchain to
test.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2022-11-19
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Is causing at least two regressions on s390-linux-gnu:
> Tests that now fail, but worked before (19 tests):
> [ ... ]
> gcc.target/s390/arch12/mul-1.c scan-assembler-times \tmsgrkc\t 1
> gcc.target/s390/arch13/sel-1.c scan-assembler-times \tselgr(?:h|le)\t 1
> [ ... ]
> 
> Those are the only two that I have positively confirmed are due to the
> emit_group_store change.
> 
> I looked briefly at the resulting assembly code for the mul-1 test and it
> looks worse to me after that change.  But I'm far from an s390 expert.

Thanks for the heads up, I'll have a quick look.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Eric, any progress on this?

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Indeed this pessimizes on s390 because it has insv instructions.  It's too late
to properly sort this out so I'm going to revert the change.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Eric Botcazou <ebotcazou@gcc.gnu.org>:

https://gcc.gnu.org/g:8b6c38ef6a7a8cc1f7cc2ff86a686e07ceab1641

commit r13-6659-g8b6c38ef6a7a8cc1f7cc2ff86a686e07ceab1641
Author: Eric Botcazou <ebotcazou@adacore.com>
Date:   Tue Mar 14 10:39:11 2023 +0100

    Revert latest change to emit_group_store

    This pessimizes on targets with insv instructions.

    gcc/
            PR rtl-optimization/107762
            * expr.cc (emit_group_store): Revert latest change.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So perhaps make it dependent on targetm.have_insv () or
targetm.have_insv () && get_traditional_extraction_insn (insn, type, mode,
                                              targetm.code_for_insv, 0, 3)
or something like that (perhaps for GCC 14)?  If it really is generally
undesirable
for targets with insv and desirable for ones without it.

[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So perhaps make it dependent on targetm.have_insv () or
> targetm.have_insv () && get_traditional_extraction_insn (insn, type, mode,
>                                               targetm.code_for_insv, 0, 3)
> or something like that (perhaps for GCC 14)?  If it really is generally
> undesirable for targets with insv and desirable for ones without it.

Yes, worth investigating at least, thanks for the suggestion.