search for: opaquebutalwaystru

...s 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 d...

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

...f he has ideas or insight? http://llvm.org/pubs/2008-02-23-TRANSACT-TangerObjBased.html -Chris > ; 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: >...

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.