Legalize and emit code for quad-precision floating point operation conversion of single-precision value to quad-precision.
Details
Diff Detail
Event Timeline
lib/Target/PowerPC/PPCISelLowering.cpp | ||
---|---|---|
801 | I imagine this just goes away since it's handled in the other patch. | |
lib/Target/PowerPC/PPCInstrVSX.td | ||
3386 | Huh? We are copying the sign of the input to itself? That seems like an unnecessary noop. Why do we need that? | |
3388 | These two patterns seem:
We will produce a different sequence for these two equivalent snippets of code and that seems wrong: __float128 test1(float *Ptr) { return *Ptr; } vs. float __attribute__((noinline)) getFromPtr(float *Ptr) { return *Ptr; } __float128 test2(float *Ptr) { return getFromPtr(Ptr); } |
lib/Target/PowerPC/PPCInstrVSX.td | ||
---|---|---|
3386 | Oh I see the motivation here - I imagine it's because of the code coming out of GCC. If that's the case, please remove this. We do not need to replicate this. The reason they use a copy-sign instruction is actually to move the value from the FPR into a VR (we use xxlor). On a side note, the instruction they use to copy scalar values between VSR's is a bit better since it allows for more parallelism (even if it doesn't provide shorter latency). But that's for a separate patch. |
lib/Target/PowerPC/PPCInstrVSX.td | ||
---|---|---|
3388 | Is this equivalent? test1 returns *Ptr which is pass in via GPR as it's a pointer to a float, whereas test2 is returning the return value from getFromPtr which is in a FPR. |
lib/Target/PowerPC/PPCInstrVSX.td | ||
---|---|---|
3388 | Well sure. Semantically they're exactly the same thing - load a 4-byte float from memory, convert to __float128 and return. |
I imagine this just goes away since it's handled in the other patch.