[Bug middle-end/67295] New: [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[Bug middle-end/67295] New: [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[ktkachov at gcc dot gnu.org]

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

            Bug ID: 67295
           Summary: [ARM][6 Regression] FAIL:
                    gcc.target/arm/builtin-bswap-1.c scan-assembler-times
                    revshne\\t 1
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ktkachov at gcc dot gnu.org
                CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
            Target: arm*

After the big copyrename patch r226901 I'm seeing these two fails on arm:
FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times rev16ne\\t 1

The reduced part from these tests is:

extern short foos16 (short);

/* revshne */
short swaps16_cond (short x, int y)
{
  short z = x;
  if (y)
    z = __builtin_bswap16 (x);
  return foos16 (z);
}


Compile with -O2.
With the new revision we generate:
        cmp     r1, #0
        rev16ne r0, r0
        uxthne  r0, r0
.L2:
        sxth    r0, r0
        b       foos16

whereas before that we generated:
        cmp     r1, #0
        revshne r0, r0
.L2:
        b       foos16


Never mind the extra label, I think that's a practically harmless artifact of
if-conversion.
My arm-none-eabi cross compiler was configured with:
--with-arch=armv7-a --with-float=hard --with-fpu=neon-vfpv4

Note, the subsequent commit:
Author: aoliva <aoliva@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Aug 19 17:00:32 2015 +0000

    [PR64164] fix regressions reported on m68k and armeb

    Defer stack slot address assignment for all parms that can't live in
    pseudos, and accept pseudos assignments in assign_param_setup_block.

    for  gcc/ChangeLog

        PR rtl-optimization/64164
        * cfgexpand.c (parm_maybe_byref_p): Renamed to...
        (parm_in_stack_slot_p): ... this.  Disregard mode, what
        matters is whether the parm will live in a pseudo or a stack
        slot.
        (expand_one_ssa_partition): Deal with params without a default
        def.  Disregard mode.
        * cfgexpand.h: Renamed function declaration.
        * tree-ssa-coalesce.c: Adjust.
        * function.c (split_complex_args): Allocate stack slot for
        unassigned parms before splitting.
        (parm_in_unassigned_mem_p): New.  Use it instead of
        parm_maybe_byref_p throughout this file.
        (assign_parm_setup_block): Use it.  Accept pseudos in the
        expand-assigned rtl.
        (assign_parm_setup_reg): Drop BLKmode requirement.
        (assign_parm_setup_stack): Allocate and fill in the address of
        unassigned MEM parms.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227015
138bc75d-0d04-0410-961f-82ee72b054a4

didn't fix this.

Let me know if any more information is needed

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Target Milestone|---                         |6.0

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[aoliva at gcc dot gnu.org]

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

--- Comment #1 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I get exactly the same code with r226900, before the copyrename patch:

        cmp     r1, #0
        rev16ne r0, r0
        uxthne  r0, r0
.L2:
        sxth    r0, r0
        b       foos16

Did you use any other configuration flags or compiler options or assembler
version or something to get you the better-optimized code?

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Alexandre Oliva from comment #1)
> I get exactly the same code with r226900, before the copyrename patch:
> 
>         cmp     r1, #0
>         rev16ne r0, r0
>         uxthne  r0, r0
> .L2:
>         sxth    r0, r0
>         b       foos16
> 
> Did you use any other configuration flags or compiler options or assembler
> version or something to get you the better-optimized code?

Hmmm, I double checked, and with r226900 before the patch I definitely get:

        cmp     r1, #0
        revshne r0, r0
.L2:
        b       foos16

The options are just -O2 -S.
It is an arm-none-eabi toolchain (with newlib as the C-library) and the
relevant configure options I can think of are:
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-fpu=neon-fp-armv8 --with-arch=armv8-a --without-isl

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Still no luck on a x86_64-linux-gnu build machine, running ../configure
--target=arm-none-eabi --disable-shared --disable-nls --disable-threads
--disable-tls --enable-checking=yes --enable-languages=c,c++,fortran
--with-newlib --with-fpu=neon-fp-armv8 --with-arch=armv8-a --without-isl
building binutils (+gdb commit db1ff28b60) and newlib (+cygwin commit
c7806ef76a) on the same tree.  I'm afraid this is going to be very hard to
debug if I can't duplicate it.  Any chance you could build a toolchain that
works on some machine on the gcc build farm, so that I could get access to it
as well and debug from there, or at least try to figure out what the
differences are between our setups?  Thanks,