public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: target/5728: GCC generated non-optimal code for Hitachi SH-4
@ 2002-03-29 18:41 rth
  0 siblings, 0 replies; 2+ messages in thread
From: rth @ 2002-03-29 18:41 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, michaels, nobody, rth

Synopsis: GCC generated non-optimal code for Hitachi SH-4

Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-By: rth
Responsible-Changed-When: Fri Mar 29 18:41:27 2002
Responsible-Changed-Why:
    .
State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Fri Mar 29 18:41:27 2002
State-Changed-Why:
    Fixed for gcc 3.1.  Current output is
    
            dmulu.l r5,r4
            nop
            sts     mach,r0
            rts     
            add     #1,r0
    
    I don't know what the nop is for (one of the sh maintainers
    would have to answer that), but the register movement issue
    has been delt with.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5728


^ permalink raw reply	[flat|nested] 2+ messages in thread

* target/5728: GCC generated non-optimal code for Hitachi SH-4
@ 2002-02-19  7:46 michaels
  0 siblings, 0 replies; 2+ messages in thread
From: michaels @ 2002-02-19  7:46 UTC (permalink / raw)
  To: gcc-gnats


>Number:         5728
>Category:       target
>Synopsis:       GCC generated non-optimal code for Hitachi SH-4
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 19 07:46:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     michaels@stochastik.rwth-aachen.de
>Release:        gcc version 3.0.4 20020215 (prerelease)
>Organization:
>Environment:
Debian Linux i686 host
Hitachi SH-4 embedded target
compiler built for sh-elf
>Description:
it seems gcc misses some quite obvious optimizations for Hitachi SH-4, and
it even got worse since V3.0.1. The behaviour described here was verified
with 3.0.3 and 3.0.4 20020215 (prerelease).

Without -frename-registers, an additional unnecessary move is generated.

The superfluous instructions are marked in the included assembly output.
>How-To-Repeat:
sh-elf-gcc -m4 -fomit-frame-pointer -Os -S -frename-registers test1.c
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="sh-gcc.txt"
Content-Disposition: inline; filename="sh-gcc.txt"

typedef unsigned long tU32;
typedef unsigned long long tU64;

tU32 test3(tU32 nus, tU32 mult)
{
  tU32 tmp = ((tU64) nus * (tU64) mult)>>32;
  return tmp + 1;
}


/opt/cgcc2/bin/sh-elf-gcc -m4 -fomit-frame-pointer -Os -S -frename-registers test1.c

        .file   "test1.c"
        .text
        .align 1
        .global _test3
        .type   _test3,@function
_test3:
        mov     r4,r2    ! this move can be eliminated
        nop              ! why is this NOP necessary?
        dmulu.l r5,r2
        sts.l   pr,@-r15 ! this can be eliminated - V3.0.1 does this!
        lds.l   @r15+,pr ! this can be eliminated - V3.0.1 does this!
        sts     mach,r0
        mov     r0,r3    ! this move can be eliminated
        rts     
        add     #1,r0
.Lfe1:
        .size   _test3,.Lfe1-_test3
        .ident  "GCC: (GNU) 3.0.4 20020215 (prerelease)"


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-03-30  2:41 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-29 18:41 target/5728: GCC generated non-optimal code for Hitachi SH-4 rth
  -- strict thread matches above, loose matches on Subject: below --
2002-02-19  7:46 michaels

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).