More floating point codegen #1599
Conversation
Conditional moves for xmm registers confused me and since this is not a common thing we yet see (I've seen it once in real code), I'm not too worried about making it perfectly fast yet.
The first of these caught a genuine bug (that we didn't handle `select` and floats properly), so it's worth running them more often.
| match inst.trueval(self.m).bitw(self.m) { | ||
| 32 => { | ||
| dynasm!(self.asm | ||
| ; bt Rd(cond_reg.code()), 0 |
There was a problem hiding this comment.
Would the fcmov instruction help here? That would bring this in parity with the integer version.
There was a problem hiding this comment.
You tell me. I ended up baffled by this; the documentation on this stuff is much sparser -- and frankly, much worse -- than for general purpose registers. Personally I'd be happy to get something we're confident is correct in and optimise it later.
There was a problem hiding this comment.
Now I look at it, fcmov uses the old fashioned floating point stack and not the xmm registers, so we can't (and shouldn't) use it.
Your codegen looks correct to me. AI tells me there is no xmm equivalent to fcmov and gave me a technique similar to what you have done here.
There was a problem hiding this comment.
Sounds like we can merge this then?
We previously didn't handle
selectwith floating point values -- which I've now seen in the wild! Please check the codegen properly for this: it made my head hurt.