public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10076: Use of function call return value
@ 2003-03-17 13:56 Gábor Lóki
  0 siblings, 0 replies; 3+ messages in thread
From: Gábor Lóki @ 2003-03-17 13:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

The following reply was made to PR optimization/10076; it has been noted by GNATS.

From: =?ISO-8859-2?Q?G=E1bor_L=F3ki?= <alga@rgai.hu>
To: rth@gcc.gnu.org,  gcc-bugs@gcc.gnu.org,  gcc-prs@gcc.gnu.org, 
 nobody@gcc.gnu.org,  gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/10076: Use of function call return value
Date: Mon, 17 Mar 2003 14:54:05 +0100

 rth@gcc.gnu.org wrote:
 
 >Synopsis: Use of function call return value
 >
 >State-Changed-From-To: open->closed
 >State-Changed-By: rth
 >State-Changed-When: Sun Mar 16 09:29:48 2003
 >State-Changed-Why:
 >    Not really a bug.  You failed to return a value from foo1.
 >    Fix that, as you did in foo2, and everything clears up.
 >
 >http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10076
 >
 >
 >  
 >
     Ok, the source code was not correct, but the problem still remains.
 
     It doesn't matter if a retrun is put at the end of foo1 or not, gcc 
 produces the same problem.
 
     ( I subbmited a new PR: 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10122 
 )
 
          In example_1 there is an unnecessary "mov r2,r0" as I descibed 
 in PR.
         There is only one problem with this example. An opimization 
 algorithm changed the
         order of instructions. So the unnecessary "mov r0,#35" is placed 
 earlier than
         "str r2,[r3,#0]" (because of unnecessary "mov r2,r0", where r0 
 is dead).
 
         In example_2 there is another unnecessary "mov r3,r0". I don't 
 know the reason of this.
 
     I hope these examples will help what the problem is!
 
 Regards,
     Gábor Lóki
 
 


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

* Re: optimization/10076: Use of function call return value
@ 2003-03-16  9:29 rth
  0 siblings, 0 replies; 3+ messages in thread
From: rth @ 2003-03-16  9:29 UTC (permalink / raw)
  To: alga, gcc-bugs, gcc-prs, nobody

Synopsis: Use of function call return value

State-Changed-From-To: open->closed
State-Changed-By: rth
State-Changed-When: Sun Mar 16 09:29:48 2003
State-Changed-Why:
    Not really a bug.  You failed to return a value from foo1.
    Fix that, as you did in foo2, and everything clears up.

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


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

* optimization/10076: Use of function call return value
@ 2003-03-14  8:16 alga
  0 siblings, 0 replies; 3+ messages in thread
From: alga @ 2003-03-14  8:16 UTC (permalink / raw)
  To: gcc-gnats

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]


>Number:         10076
>Category:       optimization
>Synopsis:       Use of function call return value
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 14 08:16:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Gábor Lóki
>Release:        GCC: (GNU) 3.3 20030303 (prerelease)
>Organization:
>Environment:
BUILD & HOST: Linux 2.4.20 i686 unknown
TARGET: arm-unknown-elf
>Description:
After a function call where the return value is stored in a hard register, GCC moves this value into a soft register. After that if an instruction uses this value, the soft register will be used.
In some cases the optimization algorithms aren't able to recognize that the soft and hard registers which hold the return value are the same. This results in an unnecessary move instruction for each arithmetic instruction that uses the return value. (In some other cases the unnecessary move is optimized out by some of the algorithms.)
In the expamle attached, in function foo1 there is an unnecessary move, while in the case of function foo2 there isn't such.
>How-To-Repeat:
arm-elf-gcc -S -g0 -Os function-call-return-value.i

int bongo(int);
int j;
int foo1()
{
  j=bongo(44);
}

void foo2()
{
  j=bongo(44);
} 
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/x-compressed; name="function-call-return-value.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="function-call-return-value.tgz"

H4sICKRAcD4AAGZ1bmN0aW9uLWNhbGwtcmV0dXJuLXZhbHVlLnRhcgDtVl1r2zAU7asM+w93CYME
bKPIH4FsHYM+9KVsD2NPYxTFlo2CLBnJztaV/vdJtrN1W0j2kLaU+fjB98v3imMfyZrRvGJnDwqM
cRrHsC/eI03O8DKNYhwtowi7eJIm5Aw/7LJ6tKahGv5e3H8CqquAiSIoswyCjxCUGIIPBopWZg1X
MsioEIFmTatlsKWiZSF/4T31okecDIde9KlmHNN/hBc/9R/HVvd4QTBJR/0/AqawgMmBjyCbeF3J
m3XLRRNw+XYXyFRVUZmD4JLtgocbcdnAWslSzaw1f935m/5WKLWYzb1bD2Bz3tfEsS2587yt4rnL
k/35pybwmePAGzOnmnFE/4sojX+d/8tB/0k86v8RgMKCC4aOKBeFDfvW2BsVvJSIWKsUak0FcsJ1
6ZuadbYPr3atPOevPPQOqC4NnAP2obadmd00OqfQtGLOdDWdcy0Zy5lL20atYeaaSiVvKtVaa2ji
oUptEa99MLWHTFMVOTL1Sx9uCxtzcaHtoOyuL9R20DSObWW7RruKqfXXAnUbiYdErpGOfAivyPAM
8UFj11x39meXneIvrrRitGvTTTN1Pym8ilb32LGNnPtV6RxtrGH49x07YTAwto9Jco9J8geT5Hkx
mQzs4X9iL/2dvWQve2Rgz7HkDh+08SH2IXI+z5ls0OTy4mIFs8v3n+YQhREQ929hL5hZtjQTjBo2
n4xHxogRA34Abi9xywAQAAA=


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

end of thread, other threads:[~2003-03-17 13:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-17 13:56 optimization/10076: Use of function call return value Gábor Lóki
  -- strict thread matches above, loose matches on Subject: below --
2003-03-16  9:29 rth
2003-03-14  8:16 alga

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