search for: indirectbr

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 pr...

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 co...

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] indirectbr i8* %...

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 indirect jump at runtime? Thanks for any advice. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists...

Hi according to [1] and [2] the blockaddress of any basic block can be obtained. But I am not sure about that fact that an indirectbr can only target at a basic block which is within the same function as the indirectbr instruction. [1] states: ---8<--- All possible destination blocks must be listed in the label list, otherwise this instruction has undefined behavior. This implies that jumps to labels defined in other function...

...ks <maurice.marks at gmail.com> wrote: > 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 indirect jump at > runtime? IIRC indirectbr isn't supported in the JIT: http://llvm.org/bugs/show_bug.cgi?id=6744 Our first cut...

On Jan 2, 2010, at 11:03 AM, Dustin Laurence wrote: > 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...

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 pr...

Consider this IR fragment produced after -O3: > %7: > %8 = phi i8* [ blockaddress(@0, %19), %19 ], [ %12, %11 ] > %9 = phi i32 [ %20, %19 ], [ 0, %11 ] > indirectbr i8* %8, [label %4, label %19] > > %19: > %20 = add nsw i32 %9, 1 > %21 = icmp eq i32 %9, 9999 > br i1 %21, label %16, label %7 the br in %19 should be optimized to branch directly to itself rather than going back to %7 (note that the arg %8 to the indirectbr will always be the addr...

...which executes when leaving a >> specific block to go to a specific successor. The only way to split an >> indirect goto is to insert code before the jump which checks for a >> specific destination address. This is very likely to be a pessimization. > Do you mean like turning a indirectbr %addr, [%a, %b, ...] > into a switch %addr, undef, [blockaddr(%a), %a], [blo > ckaddr(%b), %b], ... > ? (I know that the switch doesn't accept a pointer as first argument, it's just an example) That difference is relevant, though, because there's no way to implement such a swi...

...creates a block which executes when leaving a > specific block to go to a specific successor. The only way to split an > indirect goto is to insert code before the jump which checks for a > specific destination address. This is very likely to be a pessimization. Do you mean like turning a indirectbr %addr, [%a, %b, ...] into a switch %addr, undef, [blockaddr(%a), %a], [blo ckaddr(%b), %b], ... ? (I know that the switch doesn't accept a pointer as first argument, it's just an example) > To answer your original question, the current implementation design > for indirect goto is i...

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 indirectbr but produces an error nevertheless, will suffice.) I compile the code with: # llvm-as -o main.bc main.ll # llc -o main.s main.bc and get:...

...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 original problem is much more complicated, so i hope the reduced example, which has no indirectbr but produces an error nevertheless, will suffice.) This is because of new checking code I added, specifically to catch bugs like...

On Jul 7, 2011, at 2:05 AM, Carlo Alberto Ferraris wrote: > Consider this IR fragment produced after -O3: >> %7: >> %8 = phi i8* [ blockaddress(@0, %19), %19 ], [ %12, %11 ] >> %9 = phi i32 [ %20, %19 ], [ 0, %11 ] >> indirectbr i8* %8, [label %4, label %19] >> >> %19: >> %20 = add nsw i32 %9, 1 >> %21 = icmp eq i32 %9, 9999 >> br i1 %21, label %16, label %7 > the br in %19 should be optimized to branch directly to itself rather than going back to %7 (note that the arg %8 to the indirectb...

...direct goto is to insert code before the jump which checks for a specific destination address. This is very likely to be a pessimization. To answer your original question, the current implementation design for indirect goto is intentionally based around having a single block that terminates in an indirectbr. Otherwise the CFG of a context-threaded interpreter loop becomes inherently O(N^2): there are N instruction labels, each of which has approximately N predecessors. We rely on a code-generation optimization, tail duplication, to actually restore the context-threading behavior. In short, don'...

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 i32 -1 } The code after test_label can be reached, but this example produces also an error. Regards, Sebastian On Monday 15 March 2010 17:41:18 you wrote: > > On Mar 15, 2010, at 7:11 AM, Se...

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 bug with your test case. In the source it says "If the predecessor is an indirect goto, we can't split the edge.

...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 original problem is much more complicated, so i hope the reduced example, which has no indirectbr but produces an error nevertheless, will suffice.) > > This is because of new checking code I added, specifically...

...e 'i1', <iftrue><iffalse><dest> have to be of type 'label', why does the syntax have to specify them? lib/AsmParser/LLParser.cpp also checks these restrictions when reading a *.ll. I have the same questions for the 'label type' of 'switch' and 'indirectbr'. Thanks. -- Jianzhou

On Jul 7, 2011, at 10:15 PM, Carlo Alberto Ferraris wrote: > I'll try to inspect the assembler. Just a quick thought in the mean time, in the snippet I posted, if the backedge pointed directly to %19, other optimizations would likely notice that the loop could be removed entirely and replaced with a single addition. Do you think the code generator is able t > o do this? Why would you