[LLVMdev] RFC: Exception Handling Proposal II
John McCall
rjmccall at apple.com
Sun Nov 28 16:22:47 PST 2010
On Nov 28, 2010, at 4:15 PM, Jakob Stoklund Olesen wrote:
>
> On Nov 28, 2010, at 3:47 PM, John McCall wrote:
>
>> So mem2reg would have to split %try and make a phi in %lp, like so:
>>
>> try1: unwinds to %lp
>> %count = load i32* @count
>> br label %try2
>> try2: unwinds to %lp
>> call void foo()
>> br label %return
>> lp:
>> %t = phi i32 [ i32 0, label %try1 ], [ i32 %count, label %try2 ]
>> #etc.
>>
>> That's a lot of added complexity for mem2reg (and other transformations that use it as a subroutine), but it's pretty much inherent in any design where edges don't always come from terminators.
>>
>> Now, in this specific case, mem2reg could say "hey, %count can't throw, I don't need the phi at all". But it would still need to split %lp to make the IR well-formed; it's just that %lp1 wouldn't have an "unwinds" clause. And in the general case, it needs a phi.
>
> This problem reappears during register allocation.
>
> If a value is live-in to a landing pad, it must be kept in the same location before any instruction that may throw - a callee-saved register or a stack slot.
>
> That means the register allocator is no longer free to move values between registers and the stack inside a basic block. It would at least have to ensure that a copy is kept in a stack slot or in a fixed callee-saved register. This would be particularly bad for register classes that have no callee-saved registers, such as vector registers.
>
> This will be less of a problem if the code generator knows which instructions may throw.
Yeah, I think any proposal for attaching unwind destinations to blocks will have to include a "can unwind" bit on Instruction so that this can be tested extremely efficiently.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101128/965a8de2/attachment.html>
More information about the llvm-dev
mailing list