[PATCH] D65497: [RISCV] Generate extensions for RV64 when lowering LibCall with i32 type

[Shiva Chen via Phabricator via llvm-commits]

shiva0217 added a comment.

In D65497#1607839 <https://reviews.llvm.org/D65497#1607839>, @lenary wrote:

> I thought the problem was in that in the complex add case, we needed to zero-extend the i32 into an i64, in order to zero the upper 32 bits. This patch seems to sign-extend the libcall instead. Is there a `shouldZeroExtendTypeInLibCall` callback?


Hi @lenary,

It seems that `shouldSignExtendTypeInLibCall` control the value is signed or zero extented in TargetLowering::makeLibCall.

  ...
  bool signExtend = shouldSignExtendTypeInLibCall(RetVT, isSigned);
  ...
  CLI.setDebugLoc(dl)
      .setChain(DAG.getEntryNode())
      .setLibCallee(getLibcallCallingConv(LC), RetTy, Callee, std::move(Args))
      .setNoReturn(doesNotReturn)
      .setDiscardResult(!isReturnValueUsed)
      .setSExtResult(signExtend)
      .setZExtResult(!signExtend);

The IR before the or operation:

  t42: i64 = AssertSext t40, ValueType:ch:i32
  t45: i64 = and t42, Constant:i64<4294967295>
  t23: i64 = or t21, t45

If `shouldSignExtendTypeInLibCall` return true in this case, AssertSext will be generated and the `and` operation for zero_extend will be preserved.
If `shouldSignExtendTypeInLibCall` return false, AssertZext will be generated and the `and` operation for zero_extend will be eliminated.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65497/new/

https://reviews.llvm.org/D65497