[Bug target/65010] New: ppc backend generates unnecessary signed extension

[Bug target/65010] New: ppc backend generates unnecessary signed extension

[carrot at google dot com]

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

            Bug ID: 65010
           Summary: ppc backend generates unnecessary signed extension
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carrot at google dot com
            Target: powerpc64le

I use ppc gcc to compile following code with option -O2

unsigned long c2l(unsigned char* p)
{
  unsigned long res = *p + *(p+1);
  return res;
}

long c2sl(signed char* p)
{
  long res = *p + *(p+1);
  return res;
}


Trunk gcc generates:

c2l:
    lbz 10,0(3)
    lbz 9,1(3)
    add 3,10,9
    extsw 3,3
    blr


c2sl:
    lbz 9,1(3)
    lbz 10,0(3)
    extsb 9,9
    extsb 3,10
    add 3,3,9
    extsw 3,3
    blr


The extsw instructions in both functions are unnecessary since it can't change
the value in return register.

[Bug target/65010] ppc backend generates unnecessary signed extension

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Also seen on ppc64.  For the somewhat simpler test case (below) recent trunk
emits the following (on both ppc64 and ppc64le):

foobar:
    .quad    .L.foobar,.TOC.@tocbase,0
    .previous
    .type    foobar, @function
.L.foobar:
    addi 3,3,1
    extsw 3,3
    blr
    .long 0
    .byte 0,0,0,0,0,0,0,0
    .size    foobar,.-.L.foobar
    .ident    "GCC: (GNU) 5.0.0 20150221 (experimental)"

int foobar (signed char c) { return c + 1; }

[Bug target/65010] ppc backend generates unnecessary signed extension

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
Martin, could you attach the .optimized dump for this test.

-fdump-tree-optimized-blocks

That's usually the first place I start as it'll tell me if we're likely going
to need to look at the gimple/ssa optimizers or the rtl optimizers.

[Bug target/65010] ppc backend generates unnecessary signed extension

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Created attachment 34978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34978&action=edit
.expand RTL dump for simplified test case from comment #1.

(In reply to Jeffrey A. Law from comment #2)

Sure.  The dumps is where I started as well.  The first dump I see the sign
extension is in .expand (attached).  The .optimized dump below reflects what I
would expect: the argument is sign extended before the addition.  But the
.expand dump shows the sign extension taking place after the addition.

;; Function foobar (foobar, funcdef_no=0, decl_uid=2346, cgraph_uid=0,
symbol_order=0)

foobar (signed char c)
{
  int _2;
  int _3;

  <bb 2>:
  _2 = (int) c_1(D);
  _3 = _2 + 1;
  return _3;

}

[Bug target/65010] ppc backend generates unnecessary signed extension

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc64le                 |powerpc64-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-21
                 CC|                            |dje at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #4 from David Edelsohn <dje at gcc dot gnu.org> ---
GCC generates lots of extraneous sign-extensions and zero-extensions.  There
are ad-hoc passes in GCC that try to eliminate some.  Ken Zadeck has proposed a
general solution.

[Bug target/65010] ppc backend generates unnecessary signed extension

[wschmidt at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.seifert at de dot ibm.com

--- Comment #10 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
*** Bug 95737 has been marked as a duplicate of this bug. ***

[Bug target/65010] ppc backend generates unnecessary signed extension

[pthaugen at gcc dot gnu.org]

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

pthaugen at gcc dot gnu.org changed:

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

--- Comment #11 from pthaugen at gcc dot gnu.org ---
Another example to clean up. The back to back constant load/sign extend
sequence of rtl insns is created in each block by the block reordering pass
(.bbo) duplicating the common return block.

int foo(int in)
{
   if (in == 1)
     return 123;
   return 0;
}


foo:
.LFB0:
        .cfi_startproc
        cmpwi 0,3,1
        beq 0,.L5
        li 3,0
        extsw 3,3
        blr
        .p2align 4,,15
.L5:
        li 3,123
        extsw 3,3
        blr

[Bug target/65010] ppc backend generates unnecessary signed extension

[bergner at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org
   Last reconfirmed|2016-01-27 00:00:00         |2023-3-23

--- Comment #12 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to pthaugen from comment #11)
> Another example to clean up. The back to back constant load/sign extend
> sequence of rtl insns is created in each block by the block reordering pass
> (.bbo) duplicating the common return block.
> 
> int foo(int in)
> {
>    if (in == 1)
>      return 123;
>    return 0;
> }
> 
> 
> foo:
> .LFB0:
> 	.cfi_startproc
> 	cmpwi 0,3,1
> 	beq 0,.L5
> 	li 3,0
> 	extsw 3,3
> 	blr
> 	.p2align 4,,15
> .L5:
> 	li 3,123
> 	extsw 3,3
> 	blr

Cuurent trunk code for this is now:

foo:
        cmpwi 0,3,1
        beq 0,.L3
        li 3,0
        rldicl 3,3,0,32
        blr
        .p2align 4,,15
.L3:
        li 3,123
        rldicl 3,3,0,32
        blr

It's interested that we seem to have switched from a sign extension to a zero
extension.

[Bug target/65010] ppc backend generates unnecessary signed extension

[aagarwa at gcc dot gnu.org]

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

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

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

[Bug target/65010] ppc backend generates unnecessary signed extension

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to pthaugen from comment #11)
> Another example to clean up. The back to back constant load/sign extend
> sequence of rtl insns is created in each block by the block reordering pass
> (.bbo) duplicating the common return block.

(.bbro)

That pass is way late, so you do not get any of the more basic optimisations
after it :-(  We either need to move this pass earlier, or do this before
cprop3
and cse2 as well already, or somehow do a minimal version of all that basic
stuff
in bbro itself?