Consider this example code.
int main(string[] args) {
real x = args.length == 2 ? 6.0 : 4.0; // just to defeat the optimiser
// real y = x * 2; // (1)
real y = x + x; // (2)
return cast(int)y;
}
------------------
After the first line, x is in ST(0). Here's how the compiler calculates y.
Case (1) y = x * 2
fadd ST(0),ST
Case (2) y = x + x
fstp tbyte ptr [ESP] // store x
fld tbyte ptr [ESP] // load x
fld tbyte ptr [ESP] // load x again
faddp ST(1),ST
It's very interesting that in the first case, the compiler is able to eliminate the store of x, yet it doesn't do it in the second case.
The compiler's inability to do this is the primary cause of DMD's poor floating point performance.
Comment #1 by shro8822 — 2010-06-24T06:59:59Z
Sounds like a prime case for a keyhole optimization. Does DMD have the infrastructure in place to do that?
Comment #2 by clugdbug — 2010-06-24T12:52:21Z
(In reply to comment #1)
> Sounds like a prime case for a keyhole optimization. Does DMD have the
> infrastructure in place to do that?
Yes, there's pinholeopt() in cod3.c. But this optimisation should be done earlier.
Although it seems as though you could replace:
fstp XXX; fld XXX; with fst XXX; there's unfortunately no fst instruction for 80-bit reals, and for doubles and floats it can change the rounding.
Comment #3 by shro8822 — 2010-06-25T07:07:22Z
(In reply to comment #2)
> (In reply to comment #1)
> > Sounds like a prime case for a keyhole optimization. Does DMD have the
> > infrastructure in place to do that?
>
> Yes, there's pinholeopt() in cod3.c. But this optimisation should be done
> earlier.
Agreed, but (done wrong now) + (done right later) > (done right later)
> Although it seems as though you could replace:
> fstp XXX; fld XXX; with fst XXX; there's unfortunately no fst instruction for
> 80-bit reals, and for doubles and floats it can change the rounding.
I was primarily thinking of removing total nop cases (store+load+never used again). Also you could include a speed/accuracy trade-off flag. Or not.
Comment #4 by clugdbug — 2010-06-25T09:32:15Z
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Sounds like a prime case for a keyhole optimization. Does DMD have the
> > > infrastructure in place to do that?
> >
> > Yes, there's pinholeopt() in cod3.c. But this optimisation should be done
> > earlier.
>
> Agreed, but (done wrong now) + (done right later) > (done right later)
>
> > Although it seems as though you could replace:
> > fstp XXX; fld XXX; with fst XXX; there's unfortunately no fst instruction for
> > 80-bit reals, and for doubles and floats it can change the rounding.
>
> I was primarily thinking of removing total nop cases (store+load+never used
> again).
That's why it needs to be done earlier. pinhole doesn't know if values are used again.
Comment #5 by shro8822 — 2010-06-26T08:28:26Z
(In reply to comment #4)
> (In reply to comment #3)
> > I was primarily thinking of removing total nop cases (store+load+never used
> > again).
>
> That's why it needs to be done earlier. pinhole doesn't know if values are used
> again.
So a pinhole optimizer doesn't see enough. Got it.
Comment #6 by robert.schadek — 2024-12-13T17:52:27Z