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.
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? 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
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/