On Sat, Apr 19, 2008 at 1:27 PM, Chris Lattner <sabre at nondot.org> wrote:> On Apr 19, 2008, at 1:30 AM, Edward Lee wrote: > > It seems like LLVM happily creates function calls that pass in labels > > but doesn't know how to emit them. > Yep, this isn't supported. We can't quite enforce it as invalid at > this moment, but don't expect it to work.That's a little bit disappointing for me. Is there some way in LLVM to get the address of a label and put it in a register for use within that function? I'm using a special instruction that effectively branches to the value in that register. pseudo-LLVM: %tmp = label %label br label %tmp Except it doesn't behave like a (un)conditional branch of course; otherwise, I would just use the standard LLVM BranchInst. Ed
On Apr 19, 2008, at 12:04 PM, Edward Lee wrote:> On Sat, Apr 19, 2008 at 1:27 PM, Chris Lattner <sabre at nondot.org> > wrote: >> On Apr 19, 2008, at 1:30 AM, Edward Lee wrote: >>> It seems like LLVM happily creates function calls that pass in >>> labels >>> but doesn't know how to emit them. >> Yep, this isn't supported. We can't quite enforce it as invalid at >> this moment, but don't expect it to work. > That's a little bit disappointing for me. Is there some way in LLVM to > get the address of a label and put it in a register for use within > that function?No. The reason we don't allow this is because it violates the CFG. The compiler needs to know where and how control flow happens so that dataflow analysis and code motion does not corrupt the behavior of the program being compiled. We do plan to eventually optimize indirect goto more aggressively, but this is a big and nasty project. -Chris
On Sat, Apr 19, 2008 at 2:16 PM, Chris Lattner <sabre at nondot.org> wrote:> No. The reason we don't allow this is because it violates the CFG.So if I *don't* violate the CFG, would I still need to do something close to "big and nasty"? ; save the address of %otherPath to use later call @llvm.checkpoint(label %otherPath) ; trick the rest of the compiler to think data flows to both paths *from here* br i1 @opaqueButAlwaysTrue, label %normalPath, label %otherPath normalPath: ; do some work.. call void @work() ; rollback and erase any data changes since the checkpoint and ; continue at the label given to @checkpoint call @llvm.rollback() unreachable otherPath: ; we arrive here because @rollback reverted data to @checkpoint ; and it said to go to label %otherPath Right now I'm looking into making a new Inst that inherits BranchInst because I can give it BasicBlock*/labels and potentially change the CodeGen to emit a series of x86 instructions that does the functionality while not being optimized away by the rest of the compiler. Ed