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.