[LLVMdev] unwinds to in the CFG
Chris Lattner
sabre at nondot.org
Fri Apr 4 11:04:47 PDT 2008
On Fri, 4 Apr 2008, Dale Johannesen wrote:
> I'm chasing a wrong-codegen bug that looks very much like this, except
> that I do not have a second call to foo; I have %x being referenced in
> the
> unwinding code, where it hasn't been set. Was there a resolution for
> this?
I don't think the 'unwinds to' stuff is used on mainline by llvm-gcc.
-Chris
> On Apr 3, 2008, at 10:58 AM, Duncan Sands wrote:
>> Hi Devang,
>>>> Just as a quick recap the problem I encountered is how to deal
>>>> instructions in a block being used as operands in the unwind dest.
>>>> Such
>>>> as this:
>>>>
>>>> bb1: unwinds to %cleanup
>>>> call void @foo() ; might throw, might not
>>>> %x = add i32 %y, %z
>>>> call void @foo() ; might throw, might not
>>>> ret void
>>>> cleanup:
>>>> call void @use(i32 %x)
>>>>
>>>> The problem is that %x might not have been executed before we enter
>>>> %cleanup.
>>>
>>> This means bb1 has multiple exit points, which defeats the "single
>>> entry, single exit" idea. Did I miss anything here ?
>>
>> you are correct, this fundamental property of basic blocks is being
>> discarded. Very nasty! This is why I argued against this approach
>> in favour of the mini-basic-blocks approach, in which you have lots
>> of basic blocks which under the hood share common info to reduce
>> memory
>> usage. However Chris convinced me that in fact not that many places
>> really use that there is a single exit, and that only a wimpy quiche
>> eater would shrink at the idea of auditing all of LLVM! :)
>>
>> Ciao,
>>
>> Duncan.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list