This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: rfa (x86): 387<=>sse moves
- From: "Linthicum, Tony" <tony dot linthicum at amd dot com>
- To: "Dale Johannesen" <dalej at apple dot com>, ubizjak at gmail dot com
- Cc: paolo dot bonzini at lu dot unisi dot ch, gcc at gcc dot gnu dot org
- Date: Tue, 2 Aug 2005 11:30:39 -0500
- Subject: RE: rfa (x86): 387<=>sse moves
Hello All,
I applied the recent patches to the 7/23 snapshot, and am still seeing
some 387 to sse moves. In particular, in SpecFP's 177.mesa (matrix.c),
I'm seeing fld1's feeding moves to sse registers.
Compiled via: gcc -O3 -march=k8 -mfpmath=sse matrix.c
Thanks.
Tony
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Dale Johannesen
Sent: Monday, August 01, 2005 1:53 PM
To: ubizjak@gmail.com
Cc: paolo.bonzini@lu.unisi.ch; gcc@gcc.gnu.org
Subject: Re: rfa (x86): 387<=>sse moves
On Jul 31, 2005, at 9:51 AM, Uros Bizjak wrote:
> Hello!
>
>> With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code
>> like
>>
>> double d = atof(foo);
>> int i = d;
>>
>>
>> call atof
>> fstpl -8(%ebp)
>> movsd -8(%ebp), %xmm0
>> cvttsd2si %xmm0, %eax
>>
>>
>> (This is Linux, Darwin is similar.) I think the difficulty is that
for
>
> This problem is similar to the problem, described in PR target/19398.
> There is another testcase and a small analysis in the PR that might
> help with this problem.
Thanks, that does seem relevant. The patches so far don't fix this
case;
I've commented the PR explaining why.