ppc_libcalls
This change allows strictfp nodes with the type ppc_fp128 to be lowered to libcalls in the same manner that regular ppc_fp128 opcodes are. Unlike regular opcodes, whose expansions chain to the entry node and typically leave a dangling chain, these libcalls use the chain input of the original strictfp node and their chain outputs are used by the users of the original node.
A couple of opcodes are not lowered to libcalls- STRICT_FP_ROUND and STRICT_FP_EXTEND. Since the ppc_fp128 type is an f64 pair, truncation or extension from/to the ppc_fp128 type requires disposing one of the doubles or pairing with a new one. The code behind these also parallels normal opcodes, with a little chain finangling.
One caveat to this change is that hardware looping in the IR optimization stage does not know to expect these expansions yet, particularly when checking to see if the intrinsic will clobber the CTR register. I have a fix for this locally to be added later.
Similar comment here with the choice of _STRICT_ vs Strict_ (i.e., ExpandFloatResStrict_FMINNUM(...)).
I think the use of Strict_ follows the coding guidelines, while _STRICT_ deviates from it.