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).