[Bug target/52441] New: SH Target: Double sign/zero extensions for function arguments

[Bug target/52441] New: SH Target: Double sign/zero extensions for function arguments

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52441

             Bug #: 52441
           Summary: SH Target: Double sign/zero extensions for function
                    arguments
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: olegendo@gcc.gnu.org
                CC: kkojima@gcc.gnu.org
            Target: sh*-*-*


When passing function arguments with < 32 bits, sign/zero extension happens on
both sides of a function call: in the caller and in the callee.

int yy (char a, char b)
{
  return a + b;
}

int xx (int a, int b)
{
  return yy (a, b);
}

compiled with -Os -fno-inline:


_yy:
    exts.b    r4,r0
    exts.b    r5,r5
    rts
    add    r5,r0


_xx:
    mov.l    .L6,r0
    exts.b    r4,r4
    jmp    @r0
    exts.b    r5,r5

    .align 2
.L6:
    .long    _yy

The sign/zero extensions in the caller (_xx) are not emitted when using the
original Renesas ABI (-mrenesas), which is correct.

Maybe this double sign/zero extension has some historical reason for some ABI
backwards compatibilities in the GNU SH ABI... but shouldn't it actually be
safe to leave out the sign/zero extensions on one side of the function call
(either caller or callee)?


Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20120227 (experimental) (GCC)

[Bug target/52441] SH Target: Double sign/zero extensions for function arguments

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52441

--- Comment #1 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2012-03-01 22:00:14 UTC ---
(In reply to comment #0)
> The sign/zero extensions in the caller (_xx) are not emitted when using the
> original Renesas ABI (-mrenesas), which is correct.

Correct for efficiency, but not for robustness :-)

> Maybe this double sign/zero extension has some historical reason for some ABI
> backwards compatibilities in the GNU SH ABI... but shouldn't it actually be
> safe to leave out the sign/zero extensions on one side of the function call
> (either caller or callee)?

I don't know any historical reason but x86 uses that double sign/zero
extension too.  It wouldn't be a safe ABI change.  There can exist hand
written functions depending that behavior.  It's too late to change
the default behavior, I think.  Of course, you can add a new -m option
or function attribute changing it, though it shouldn't be default for
non Renesas ABI.

[Bug target/52441] SH Target: Double sign/zero extensions for function arguments

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52441

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-03-01
         AssignedTo|unassigned at gcc dot       |olegendo at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-03-01 22:13:23 UTC ---
(In reply to comment #1)
> 
> I don't know any historical reason but x86 uses that double sign/zero
> extension too.  It wouldn't be a safe ABI change.  There can exist hand
> written functions depending that behavior.  It's too late to change
> the default behavior, I think.  Of course, you can add a new -m option
> or function attribute changing it, though it shouldn't be default for
> non Renesas ABI.

Right, thanks!  I haven't thought of the hand-written asm code scenario.  This
can turn into a funny problem indeed.

I'll go the option way, then.

[Bug target/52441] SH Target: Double sign/zero extensions for function arguments

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement