Gordon Henriksen wrote:> What blocks would a phi node in %catch require for a case like this? > > define i8 @f(i1 %b) { > > entry: > > b label %try > > try: unwinds to %catch > > b i1 %b, label %then, label %else > > then: unwinds to %catch > > ret void > > else: unwinds to %catch > > ret void > > catch: ; What are my predecessors? > > ret void > > }'catch' has 3 preds, %try, %then and %else.> >> B. redefine the dominator tree by modifying the GraphTraits >> i. A dom B means that all instructions in A are guaranteed to >> execute before any instructions in B. >> ii. the domtree may have multiple roots. >> >> Multiple roots occurs when the entry block 'unwinds to' another block. > > It seems highly problematical that static allocas might not dominate > their uses.I'm not sure what you mean by that. It would be invalid to "alloca" in a BB then use the pointer in the unwind dest. You can't escape that. The entry block is already special in that it cannot be used> as a branch target. Why not also forbid 'unwinds to' on the entry block?Yes, we could also do that. I'm all for hearing arguments for and opposed. Nick
On 2008-03-29, at 00:57, Nick Lewycky wrote:> Gordon Henriksen wrote: > >> What blocks would a phi node in %catch require for a case like this? >> >> define i8 @f(i1 %b) { >> entry: >> b label %try >> try: unwinds to %catch >> b i1 %b, label %then, label %else >> then: unwinds to %catch >> ret void >> else: unwinds to %catch >> ret void >> catch: ; What are my predecessors? >> ret void >> } > > 'catch' has 3 preds, %try, %then and %else.Would it be more natural to claim %entry and %try as the predecessors? This is similar to how a high level language disallows variable declarations from a try block to be visible from the catch. object x; try { x = null; } catch { use(x); } // error, x is uninitialized Also, consider a phi node: phi i32 [%x, %bb1] ; %x defined in %bb1. Depending on what type of predecessor %bb1 is, some of the models you've mentioned declare this phi node illegal.>>> B. redefine the dominator tree by modifying the GraphTraits >>> i. A dom B means that all instructions in A are guaranteed to >>> execute before any instructions in B. >>> ii. the domtree may have multiple roots. >>> >>> Multiple roots occurs when the entry block 'unwinds to' another >>> block. >> >> It seems highly problematical that static allocas might not >> dominate their uses. > > I'm not sure what you mean by that. It would be invalid to "alloca" > in a BB then use the pointer in the unwind dest. You can't escape > that.I'm just giving an example of something that breaks if the entry-block- dominates-all-blocks property is violated. Front-ends and transformations rely upon this property by unconditionally placing their 'local variable declaration' allocas in the entry block. — Gordon
Gordon Henriksen wrote:> On 2008-03-29, at 00:57, Nick Lewycky wrote: > >> Gordon Henriksen wrote: >> >>> What blocks would a phi node in %catch require for a case like this? >>> >>> define i8 @f(i1 %b) { >>> entry: >>> b label %try >>> try: unwinds to %catch >>> b i1 %b, label %then, label %else >>> then: unwinds to %catch >>> ret void >>> else: unwinds to %catch >>> ret void >>> catch: ; What are my predecessors? >>> ret void >>> } >> 'catch' has 3 preds, %try, %then and %else. > > Would it be more natural to claim %entry and %try as the predecessors? > This is similar to how a high level language disallows variable > declarations from a try block to be visible from the catch.In LLVM the rule is that an instruction must be dominated by its operands. Predecessors and successors don't enter into it, except to define the dominance tree.> object x; > try { x = null; } > catch { use(x); } // error, x is uninitialized >Yes, I know. I'm planning to accomplish this by defining pred/succ sensibly such that we get a domtree where the equivalent LLVM code would be invalid.> Also, consider a phi node: > > phi i32 [%x, %bb1] ; %x defined in %bb1. > > Depending on what type of predecessor %bb1 is, some of the models > you've mentioned declare this phi node illegal.Oh. Now that's a very good point. bb1: unwinds to %cleanup %x = add i32 @foo, @bar ret i32 %x cleanup: %y = phi i32 [%x, bb1] If %cleanup has %bb1 as a predecessor then the above is legal. (PHI nodes being the only Instruction that works on pred/succ and not dominators.) And you're right, the fix for that it to make the predecessor be bb1's preds (if it has any). This is nastier than I was expecting... Nick