[llvm] [llvm][CodeGen] Intrinsic `llvm.powi/ldexp.*` code gen for vector arguments (PR #118242)

[Craig Topper via llvm-commits]

================
@@ -2585,6 +2585,8 @@ SDValue DAGTypeLegalizer::PromoteIntOp_ExpOp(SDNode *N) {
                              : RTLIB::getLDEXP(N->getValueType(0));
 
   if (LC == RTLIB::UNKNOWN_LIBCALL || !TLI.getLibcallName(LC)) {
+    if (N->getValueType(0).isVector())
+      return DAG.UnrollVectorOp(N);
----------------
topperc wrote:

> see how there are no other UnrollVectorOps uses in DAGTypeLegalizer

There are calls to `UnrollVectorOps` in several places in LegalizeVectorTypes.cpp

This comment where the libcall below is created seems relevant

```
  // We can't just promote the exponent type in FPOWI, since we want to lower
  // the node to a libcall and we if we promote to a type larger than
  // sizeof(int) the libcall might not be according to the targets ABI.
```

My suggestion to unroll here was so that we wouldn't promote past sizeof(int). If we wait until LegalizeDAG.cpp to unroll the operation, the damage to the integer type has already been done. For RISC-V its harmless because `signed int` is supposed to be passed sign extended to 64-bits according to the ABI.

Hypothetically, if powi took an `unsigned int` as an argument, then type legalization would use zero extend, but the RISC-V ABI wants `unsigned int` to be passed sign extended. So LegalizeDAG would need to insert a SIGN_EXTEND_INREG to fix. I guess it would need to use the getIntSize() and shouldSignExtendTypeInLibCall to know what it needs to do in that case.

If we don't unroll here I guess the best fix in LegalizeDAG would also be to use `getIntSize()` and `shouldSignExtendTypeInLibCall` and use computeNumSignBits to know if a SIGN_EXTEND_INREG needs to be inserted?

https://github.com/llvm/llvm-project/pull/118242