Hi Jay,> Are you saying that, in the LLVM IR, it would be legal to have an > llvm.eh.exception that *isn't* dominated by convokes (because there's > a direct branch to that catch block), and in that case the call > returns an undefined value?this is already the case (with invoke substituted for convoke). And it would be up to codegen to "peel it> out into its own basic block"?Not sure what that means? Ciao, Duncan.
>> Are you saying that, in the LLVM IR, it would be legal to have an >> llvm.eh.exception that *isn't* dominated by convokes (because there's >> a direct branch to that catch block), and in that case the call >> returns an undefined value? > > this is already the case (with invoke substituted for convoke).Good to know. It would be nice if this was clearly documented!>> And it would be up to codegen to "peel it out into its own basic block"? > > Not sure what that means?I was trying to work out what Bill meant by this:> The only other problem I can see is if code branches into a catch block. It's gross, but could happen. In that case, the llvm.eh.exception should *not* be executed, because it's metadata constructed by the compiler, not user code. It would have to be peeled out into its own basic block in such instances.What exactly would be "peeled out into its own basic block", by whom, at what stage of the compilation process? Thanks, Jay.
>>> And it would be up to codegen to "peel it out into its own basic block"? >> Not sure what that means? > > I was trying to work out what Bill meant by this: > >> The only other problem I can see is if code branches into a catch block. It's gross, but could happen. In that case, the llvm.eh.exception should *not* be executed, because it's metadata constructed by the compiler, not user code. It would have to be peeled out into its own basic block in such instances. > > What exactly would be "peeled out into its own basic block", by whom, > at what stage of the compilation process?I think he is saying: "what happens if the unwind label for an invoke is a basic block which is also jumped to by ordinary code, not just by invokes?" The answer is that this is all already taken care of and you get the correct value. Ciao, Duncan.
On Nov 24, 2009, at 5:42 AM, Jay Foad wrote:>>> Are you saying that, in the LLVM IR, it would be legal to have an >>> llvm.eh.exception that *isn't* dominated by convokes (because >>> there's >>> a direct branch to that catch block), and in that case the call >>> returns an undefined value? >> >> this is already the case (with invoke substituted for convoke). > > Good to know. It would be nice if this was clearly documented! > >>> And it would be up to codegen to "peel it out into its own basic >>> block"? >> >> Not sure what that means? > > I was trying to work out what Bill meant by this: > >> The only other problem I can see is if code branches into a catch >> block. It's gross, but could happen. In that case, the >> llvm.eh.exception should *not* be executed, because it's metadata >> constructed by the compiler, not user code. It would have to be >> peeled out into its own basic block in such instances. > > What exactly would be "peeled out into its own basic block", by whom, > at what stage of the compilation process? >That wasn't clear. :-) This should be totally doable by the front-end, since it's the one generating the llvm.eh.exception() call. -bw