On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote:> On Jul 22, 2011, at 10:29 PM, Bill Wendling wrote: > >> // Restrictions: >> >> There are several new invariants which will be enforced by the verifier: >> >> 1. A landing pad block is a basic block which is the unwind destination of an >> invoke instruction. >> 2. A landing pad block must have a landingpad instruction as its first non-PHI >> instruction. >> 3. The landingpad instruction must be the first non-PHI instruction in the >> landing pad block. >> 4. Like indirect branches, splitting the critical edge to a landing pad block >> requires considerable care, and SplitCriticalEdge will refuse to do it. >> 5. All landingpad instructions in a function must have the same personality >> function. > > Could we add: > > - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. > > - The landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or following non-phi instructions. >Most of this is covered by 2&3. But it would be good to explicitly state that a landingpad instruction can appear only in a landing pad block.> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function?Splitting a critical edge, especially in this case, isn't necessary for correctness. It's an optimization. In general, the use of a value in the catch blocks will access that value via memory. It also complicates the SplitCriticalEdge function, like you outlined.> Will it be possible to split landing pads during codegen?Split a landing pad or split the critical edges to a landing pad? If the former, then yes. You can also split a landing pad in LLVM IR. You just can't split the landing pad block before the landingpad instruction. -bw
On Jul 23, 2011, at 1:11 AM, Bill Wendling wrote:> On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: >> Could we add: >> >> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. >> >> - The landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or following non-phi instructions. >> > Most of this is covered by 2&3. But it would be good to explicitly state that a landingpad instruction can appear only in a landing pad block.Right. I think we agree on the intention. I wanted to make it completely clear that: - All unwind edges go to a block with a landingpad instruction. - All non-unwind edges go to a block without a landingpad instruction. That then implies that unwind edges can't be split and landingpad instructions can't be moved.>> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function? > > Splitting a critical edge, especially in this case, isn't necessary for correctness. It's an optimization.Yes. You scared me with 'requires considerable care'. Does that mean anything other than 'you have to duplicate the landing pad instead of splitting the unwind edge'. Is special magic required to duplicate a landingpad instruction?> In general, the use of a value in the catch blocks will access that value via memory.Because the register allocator will spill, or because mem2reg fails? Won't there be a lot of IR values live across an unwind edge after mem2reg?> It also complicates the SplitCriticalEdge function, like you outlined.Yes, I agree. Duplicating a landing pad is different than splitting a critical edge.>> Will it be possible to split landing pads during codegen? > > Split a landing pad or split the critical edges to a landing pad?Sorry, I meant duplicating a landing pad. Landing pads notoriously collect critical edges. We should make sure there is some way of dealing with that, unlike indirectbr edges. The possibility of splitting and duplicating landing pads would help. /jakob
On Jul 23, 2011, at 2:00 AM, Jakob Stoklund Olesen wrote:> On Jul 23, 2011, at 1:11 AM, Bill Wendling wrote: > >> On Jul 22, 2011, at 11:44 PM, Jakob Stoklund Olesen wrote: >>> Could we add: >>> >>> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. >>> >>> - The landingpad instruction must only appear at the top of a landing pad. It cannot appear in any other block, or following non-phi instructions. >>> >> Most of this is covered by 2&3. But it would be good to explicitly state that a landingpad instruction can appear only in a landing pad block. > > Right. I think we agree on the intention. I wanted to make it completely clear that: > > - All unwind edges go to a block with a landingpad instruction. > - All non-unwind edges go to a block without a landingpad instruction. > > That then implies that unwind edges can't be split and landingpad instructions can't be moved. > >>> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function? >> >> Splitting a critical edge, especially in this case, isn't necessary for correctness. It's an optimization. > > Yes. You scared me with 'requires considerable care'. Does that mean anything other than 'you have to duplicate the landing pad instead of splitting the unwind edge'. Is special magic required to duplicate a landingpad instruction? >There shouldn't be any special magic involved. As you pointed out, we'd have to duplicate the landingpad instruction into each of the critical edge blocks.>> In general, the use of a value in the catch blocks will access that value via memory. > > Because the register allocator will spill, or because mem2reg fails? Won't there be a lot of IR values live across an unwind edge after mem2reg? >The register allocator should be spilling most variables across the unwind edge. The only ones which can stick around are those that are placed in non-volatile registers. This is all opaque to the IR, which doesn't know that the unwind edge is special. This is why we can have PHI nodes in the landing pad. I'm assuming that it gets it "right" because it's keeping values alive across the invoke.>> It also complicates the SplitCriticalEdge function, like you outlined. > > Yes, I agree. Duplicating a landing pad is different than splitting a critical edge. > >>> Will it be possible to split landing pads during codegen? >> >> Split a landing pad or split the critical edges to a landing pad? > > Sorry, I meant duplicating a landing pad. > > Landing pads notoriously collect critical edges. We should make sure there is some way of dealing with that, unlike indirectbr edges. The possibility of splitting and duplicating landing pads would help. >One way to get around this is to do what Andy suggested to me at one point (not on email). We could have one landing pad block per invoke instruction. So no two invokes could ever share a landing pad (and of course the landingpad instruction). (My apologies to Andy if I misrepresented his idea.) I think of this as overkill, but if you feel strongly that not being able to break critical edges is going to hamper code-gen significantly we can discuss this. -bw