similar to: Seeking clarification about indirect critical edges

That makes way more sense, thank you so much! >From your description it sounds like you were assuming that “D1”, rather > than “D0B”, is the original block “D”. In the source, “D1” is “BodyBlock” > and “D”/”D0”/”D0B” are “Target” (and “D0A” is “DirectSucc”). > I’d guess that the “easy cases” remark corresponds to bailing out on EH > pads. Yeah I could see how exception handling

Nella citazione martedì 2 agosto 2011 20:02:08, Michael Ilseman ha scritto: > I'm assuming that you're talking about a situation where this can't be > determined statically in the existing LLVM IR, but you know it's true > and want to put it in (e.g. you're the one generating LLVM IR). Correct. Or, more precisely, I'd like to investigate macro compression, i.e.

If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about the post, this is a good thread to discuss them on :) -Chris

On 2010-01-03 10:33, Chris Lattner wrote: > If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: > http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html > > This feature was added to LLVM by Bob Wilson, Dan Gohman and I to mainline back in November. If you have questions or comments about

Nella citazione martedì 2 agosto 2011 22:01:13, Carlo Alberto Ferraris ha scritto: > My question is: > what is the best way to > express such relationships in LLVM IR ("best" in the sense of allowing > other optimizations to run effectively)? Bear in mind that in this > example N=2, but it may be way bigger than that. Just to clarify: I already figured out two ways to

2010/1/3 Török Edwin <edwintorok at gmail.com>: > On 2010-01-03 10:33, Chris Lattner wrote: >> If you're interested in this new extension, here is some more information with some less-than-obvious aspects of the design: >> http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html >> >> This feature was added to LLVM by Bob Wilson, Dan Gohman and

In my llvm jit project I needed to lookup BB addresses at execution time and then jump to the corresponding BB. A C++ routine called at runtime from IR finds the right BB, gets its BlockAddress and returns it as an i8*. The IR does an indirectbr on this value... Well, not really. The routine returns the address of a BlockAddress node. Is there any way to get the real runtime code address for the

Hi, i ran into a problem when using blockaddress() with a label in another function. It seems to me that LLVM tries to remove the label used in blockaddress because it seems like it is not used, but in fact it may be used somewhere with a indirectbr. I attached a small test-case that produces this error. (The original problem is much more complicated, so i hope the reduced example, which has no

On Mar 15, 2010, at 7:11 AM, Sebastian Schlunke wrote: > Hi, > > i ran into a problem when using blockaddress() with a label in another function. It seems to me that LLVM tries to remove the label used in blockaddress because it seems like it is not used, but in fact it may be used somewhere with a indirectbr. > > I attached a small test-case that produces this error. (The

I see. But the block does not necessarily contain dead code. My original problem is more like this: define i32 @main() { entry: %target = bitcast i8* blockaddress(@test_fun, %test_label) to i8* call i32 @test_fun(i8* %target) ret i32 0 } define i32 @test_fun(i8* %target) { entry: indirectbr i8* %target, [label %test_label] test_label: ; assume some code here... br label %ret ret: ret

Hi, How does the requirement that phi instructions have one value per predecessor basic block interact with indirectbr instructions? For instance, take the following code: L1: br i1 %somevalue, label %L2, label %L3 L2: %ret1 = i8* blockaddress(@myfunction, %L5) br label %L4 L3: %ret2 = i8* blockaddress(@myfunction, %L6) br label %L4 L4: %ret = phi i8* [%ret1, L2], [%ret2, L3]

> We'd have to hoist a + b to somewhere that dominates L1 and L2. I think the only BB in your program that dominates is the entry block I don't follow. What path do you see from entry to either L1 or L2 that doesn't pass through the indirectbr? In order to reach either L1 or L2, the call to maybe_throw() must raise an exception (else we'd return 0 from foo), the exception must

Hello, I have a question about the indirectbr instruction. I attempted to use it according to the example in the Assembly Language Reference manual, but got an "expected instruction opcode" error. Poking about on the web I found this document: http://nondot.org/sabre/LLVMNotes/IndirectGoto.txt which appears to be a Nov 2, 2009 proposal to add indirectbr and blockaddress() to the IR

Hi, I encountered an error while trying to use the indirectbr instruction with Alpha backend (current build). Here's part of the code sequence that I tried to compile: bb1: %1 = load i32* %i, align 4 %2 = add nsw i32 %1, 1 store i32 %2, i32* %i, align 4 indirectbr i8* blockaddress(@main, %bb1), [ label %bb1 ] br label %return This compiles correctly when I use the X86 or PPC

Hey all, As most of you know, I've been having problems (hopefully solved by now, won't know until friend is able to reshare his box) with SAMBA over the internet. On my local area network, I am using SAMBA for a one way connection just fine. my question is as follows. Can I make an fstab entry so I can mount the XP share whenever I boot? The reason I ask is because currently Wine

Nella citazione giovedì 7 luglio 2011 19:41:16, John McCall ha scritto: > On Jul 7, 2011, at 4:33 AM, Carlo Alberto Ferraris wrote: >> Il 07/07/2011 11:14, Cameron Zwarich ha scritto: >>> I haven't read the code in detail, but it looks like JumpThreading at >>> least attempts to thread across indirect branches. You can either try >>> to fix it or file a

Hi, Thanks for the pointers. My patch now calls the attribute "noduplicate", and updates CodeMetrics to have another field: bool notDuplicatable; Which semantically is "containsIndirectBr || containsNoDuplicateInst". I didn't repurpose containsIndirectBr because I felt what I'm looking for is sufficiently different (indirectbr inhibits inlining, whereas noduplicate

Referring to the log messages from my previous mail… I confused myself (and probably others) by reading the “Adding MemMgr 0x55555959f440“ message as “Registering MemMgr 0x55555959f440”. Thus the address mismatch made no sense. How could we be registering a `MemMgr` address/key that does not match once we arrive in `notifyObjectLoaded` method? Answer: Because the registrations is NOT coming

Hi, I need to addDestination to some basic blocks I used the following code Value* Address; IndirectBrInst *IBI = IndirectBrInst::Create(Address, Result.size(),i->getTerminator() ); IBI->addDestination(i); The following error was issued void llvm::IndirectBrInst::init(llvm::Value *, unsigned int): Assertion `Address && Address->getType()->isPointerTy() &&

Hi Reid and David, I just wanted to give you a heads up that I'm currently working on a problem where the WinEHPrepare outlining code stumbles and asserts while cloning code that references extracted landing pad values via PHI nodes that are in intermediate blocks that aren't being cloned. The test I'm looking at fails with an assertion claiming that llvm.eh.begincatch was called