Bug 15228 - [3.4/4.0 Regression] useless copies of floating point operands
Summary: [3.4/4.0 Regression] useless copies of floating point operands
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.4.1
Assignee: Richard Henderson
URL:
Keywords: missed-optimization
Depends on:
Blocks:
 
Reported: 2004-04-30 15:41 UTC by Sylvain Pion
Modified: 2004-10-30 21:11 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 2.95.3
Known to fail: 3.0.4 3.2.3 3.3.3 3.4.0 4.0.0
Last reconfirmed: 2004-04-30 15:57:08


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Pion 2004-04-30 15:41:53 UTC
Consider the following function :

// Forces a double to memory
double force2memdouble(double x) {
  asm("" : "=m"(x) : "m"(x));
  return x;
}

This is used to force a double value in memory for platforms like x86
where the FP registers have too much precision.

It gets compiled by GCC (3.4 and 3.3.3, with -O2 -fomit-frame-pointer) to :

force2memdouble:
        subl    $12, %esp
        fldl    16(%esp)
        fstpl   (%esp)
        fldl    (%esp)
        addl    $12, %esp
        ret

I believe that the store/load is useless, and that the function could be
compiled as simply :

force2memdouble:
        fldl    4(%esp)
        ret


It is interesting to note that when using "int", "float" or "long double"
instead of "double", then there is no such useless store/load.


So, is this something that could be improved in GCC ?

Maybe the code responsible for asm() adds too many requirements
on the operands for doubles ?
Comment 1 Sylvain Pion 2004-04-30 15:51:07 UTC
I still have gcc 2.95 around, so I have tested with it as well.
It produces the better code that I expected :

force2memdouble:
#APP
#NO_APP
        fldl 4(%esp)
        ret


So, if the code is correct, then this problem is a regression on code quality
compared to 2.95.


I want to mention that this asm() is critical when implementing interval
arithmetic.  Also, GMP uses that kind of asm() in mpz_get_d_2exp.
Comment 2 Andrew Pinski 2004-04-30 15:57:08 UTC
Note before 3.3 and after 2.95.3, the following sequence was used to copy the FP:
        subl    $12, %esp
        movl    16(%esp), %edx
        movl    20(%esp), %ecx
        movl    %edx, (%esp)
        movl    %ecx, 4(%esp)

Confirmed as a regression.
Comment 3 Gabriel Dos Reis 2004-05-16 22:11:39 UTC
Will not fix in 3.3.x.

-- Gaby
Comment 4 Mark Mitchell 2004-05-31 22:10:04 UTC
Richard --

Would you please take a look at this?

Thanks,

-- Mark
Comment 5 Richard Henderson 2004-06-07 19:27:33 UTC
Testing a patch.
Comment 6 GCC Commits 2004-06-08 16:45:21 UTC
Subject: Bug 15228

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	rth@gcc.gnu.org	2004-06-08 16:44:56

Modified files:
	gcc            : ChangeLog function.c 

Log message:
	PR middle-end/15228
	* function.c (assign_parms): Always set_mem_align with the computed
	FUNCTION_ARG_BOUNDARY.  Don't clear stack_parm if !STRICT_ALIGNMENT.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.481&r2=2.2326.2.482
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.483.4.13&r2=1.483.4.14

Comment 7 GCC Commits 2004-06-09 23:52:17 UTC
Subject: Bug 15228

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-06-09 23:52:15

Modified files:
	gcc            : ChangeLog function.c 

Log message:
	PR middle-end/15228
	* function.c (assign_parms): Always set_mem_align with the computed
	FUNCTION_ARG_BOUNDARY.  Don't clear stack_parm if !STRICT_ALIGNMENT.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.3901&r2=2.3902
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.520&r2=1.521

Comment 8 Richard Henderson 2004-06-09 23:52:49 UTC
Fixed.