[PATCH] D18108: Swift Calling Convention: SelectionDAGBuilder changes to support swifterror
Quentin Colombet via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 4 17:49:05 PDT 2016
qcolombet added inline comments.
================
Comment at: lib/CodeGen/SelectionDAG/FastISel.cpp:1361
@@ -1351,1 +1360,3 @@
+ if (shouldCopySwiftErrorsToFinalVRegs(TLI, FuncInfo))
+ return false;
if (!handlePHINodesInSuccessorBlocks(I->getParent())) {
----------------
manmanren wrote:
> If we need to materialize the vreg from worklist (i.e shouldCopySwiftErrorsToFinalVRegs returning true), we bail out of FastISel, so we should not need to call handlePHINodesInSuccessorBlocks?
>
> Oops, forgot to update the comment.
Ah make sense. Are you planning to update the comment?
================
Comment at: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5724
@@ +5723,3 @@
+ HasSwiftError = true;
+ // A function can only have a single swifterror argument. And if it does
+ // have a swifterror argument, it must be the first entry in
----------------
manmanren wrote:
> + /// A function can only have a single swifterror argument. And if it does
> + /// have a swifterror argument, it must be the first entry in
> + /// SwiftErrorVals.
> + SwiftErrorValues SwiftErrorVals;
>
> When setting up SwiftErrorVals, we always put the argument as the first entry, so findSwiftErrorVReg should return SwiftErrorMap[FuncInfo.MBB][0].
Couldn’t we feed the argument with another swift error?
E.g.,
define void @foo(swift error %a)
%b = alloca swift error
call void @bar(%b) ; <— Here b is not in the first value in swifterrorvals, does it?
http://reviews.llvm.org/D18108
More information about the llvm-commits
mailing list