optimization/10076: Use of function call return value

alga@rgai.hu alga@rgai.hu
Fri Mar 14 09:01:00 GMT 2003


>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=



More information about the Gcc-bugs mailing list