[PowerPC] Change CTR clobber estimation for 128-bit floating types

[qiucf]

Summary

Restrict fpext and fptrunc cast instructions to/from fp128.

We need a more complete fix to defer CTR clobber judgement after instruction selection. See D81353.

[qiucf]

Fix check for fcmp because its result type is not float

[shchenz]

llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp

663

I think we are trying to handle fpext/fptrunc for fp128 type? If so, can we just explicitly handle them like:

} else if (isa<FPTruncInst>(J) && cast<FPTruncInst>(J)->getSrcTy()->getScalarType()->isFP128Ty()) {
  return true;
} else  if (isa<FPExtInst>(J) && cast<FPExtInst>(J)->getDestTy()->getScalarType()->isFP128Ty()) {
  return true;
}

Your patch seems not only change instructions FPTruncInst and FPExtInst. As you may have noted, ctr clobber check here is very sensitive especially for fp128/ppc_fp128. We met several issues before.

And have you checked with ppc_fp128 for the above two instructions FPTruncInst and FPExtInst? Can we expand them on PowerPC without potential writing ctr?

[qiucf]

llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp

663

Yes. Because of the structure of ppc_fp128:

• fptrunc ppc_fp128 %a to double: nothing (just return first fpr)
• fptrunc ppc_fp128 %a to float: xsrsp (trunc the first fpr to float)
• fpext double %a to ppc_fp128: xxlxor (set the second part as zero)
• fpext float %a to ppc_fp128: xxlxor (set the second part as zero)

[shchenz]

Thanks for fixing this. LGTM

[nemanjai]

I think that since we still keep getting issues with this after so many years and so many changes, we should just reject any operations on IBM double-double and fp128 until we refactor the code as suggested previously.

[qiucf]

Restrict all operations with ppc_fp128/fp128 result type