https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #7 from Julian Seward <jsew...@acm.org> ---
(In reply to Tom Hughes from comment #6)
> Note that I didn't mean spills/reloads that valgrind's internal
> implementation does, but rather any spills/reloads that the original
> compiler generated.
Yes -- that's also what I meant.
> Are you saying that gcc instead allocates an 80 bit temporary
> location for the spill to avoid losing precision?
Well I *thought* that was the case, but it seems I am wrong. Using
this spill-inducing loop
int main ( int argc, char** argv )
{
double a, b, c, d, e, f, g, h;
a=b=c=d=e=f=g=h=1.2345;
int i;
for (i = 0; i < 1234 * argc; i++) {
a += i * 1.2;
b += a * 1.3;
c += d / 1.4;
d += e - 1.5;
e += f + 1.6;
f += g - 1.7;
g += h * 1.8;
h += a - (b*c) + (d*e*f/g);
}
return (a-b-c-d-e-f-g-h > 987.345 ? 1 : 0);
}
I get the assembly (for the loop body) below, which uses 64-bit loads
and stores (fstpl -16(%ebp), fmull -16(%ebp), etc) with gcc6 -m32 -O2.
To get 80-bit accesses (fstpt, fldt) I need to change the declaration
to be "long double".
Ah well. Live and learn. Now I am wondering why I believed gcc did
always do 80-bit spills/reloads.
.L3:
movl %eax, -28(%ebp)
addl $1, %eax
fildl -28(%ebp)
cmpl %edx, %eax
fmull .LC1
faddp %st, %st(1)
fldl .LC2
fmul %st(1), %st
faddl -24(%ebp)
fld %st(0)
fstpl -24(%ebp)
fldl .LC3
fdivr %st(7), %st
faddl -16(%ebp)
fstpl -16(%ebp)
fld %st(3)
fsubs .LC4
faddp %st, %st(7)
fldl .LC5
fadd %st(5), %st
faddp %st, %st(4)
fldl .LC6
fsubr %st(6), %st
faddp %st, %st(5)
fldl .LC7
fmul %st(3), %st
faddp %st, %st(6)
fld %st(6)
fmul %st(4), %st
fmul %st(5), %st
fdiv %st(6), %st
fxch %st(1)
fmull -16(%ebp)
fsubr %st(2), %st
faddp %st, %st(1)
faddp %st, %st(2)
jne .L3
--
You are receiving this mail because:
You are watching all bug changes.
