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

Craig Topper via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 6 20:50:31 PST 2024


================
@@ -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:

> It makes more sense to me to handle this when emitting the call, where ABI constraints would naturally be handled. This can be sign extended here, and the call emission can truncate or sext_inreg as required

The POWI code in LegalizeDAG calls `SelectionDAGLegalize::ExpandFPLibCall` which  will call `TargetLowering::makeLibCall` using the promoted type. `makeLibCall` calls `getTypeForEVT` which will return `i64` due to the promotion. That's what will be used by calling lowering, but that's the wrong type for it to do the right thing. We need to get an i32 Type* into call lowering, but we no longer have it. We'll need to call getIntSize() to get the size and pass it along somehow. That requires refactoring several interfaces or adding new ones. Not sure if call lowering would also expect the SDValue for the argument to have i32 type.

My unrolling proposal avoided that by scalarizing it and letting the newly created scalar powi calls get converted to libcalls while we're still in type legalization. That's how we currently handle the scalar powi case. Are you also suggesting we should move the scalar handling to LegalizeDAG as well?

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


More information about the llvm-commits mailing list