[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