similar to: [LLVMdev] indirectbr/blockaddress question

On Sat, Dec 11, 2010 at 4:19 PM, Maurice Marks <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

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

On Mar 15, 2010, at 9:41 AM, Chris Lattner wrote: > > 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

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, 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

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]

On Mar 15, 2010, at 10:01 AM, Sebastian Schlunke wrote: > I see. But the block does not necessarily contain dead code. This case is now fixed in r98566, I will fix the 'dead block' case in a bit. -Chris > > My original problem is more like this: > > define i32 @main() { > entry: > %target = bitcast i8* blockaddress(@test_fun, %test_label) to i8* > > call

I'm trying to figure out how to feed a blockaddress to a switch condition AND destination (basically emulating an indirectbr via a switch; I know it's not a good approach, I'm just experimenting). Suppose I have the following: SwitchInst *s = SwitchInst::Create(...); BasicBlock *bb = ...; PtrToIntInst k = new PtrToIntInst(BlockAddress::get(bb), <TYPE>, "", s);

Works like a charm! Thanks for the fast help. :) - Sebastian On Monday 15 March 2010 20:10:54 you wrote: > > On Mar 15, 2010, at 10:01 AM, Sebastian Schlunke wrote: > > > I see. But the block does not necessarily contain dead code. > > This case is now fixed in r98566, I will fix the 'dead block' case in a bit. > > -Chris > > > > > My

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

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

Hi all, I have a question concerning block address class in LLVM. I am currently working on a project where I need to obtain and manipulate basic block virtual addresses. I was searching the web and found the llvm::BlockAddress class (http://llvm.org/doxygen/classllvm_1_1BlockAddress.html). With this class I was able to obtain a printout like this: i8* blockaddress(@func_name, %bb_label) How do

On Sun, Jul 31, 2011 at 7:36 AM, Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > I'm trying to figure out how to feed a blockaddress to a switch condition > AND destination (basically emulating an indirectbr via a switch; I know it's > not a good approach, I'm just experimenting). > Suppose I have the following: > > SwitchInst *s =

On Mon, Apr 16, 2018 at 04:14:03PM -0400, Brenda So via llvm-dev wrote: > Hi all, > > I have a question concerning block address class in LLVM. I am currently > working on a project where I need to obtain and manipulate basic block virtual > addresses. I was searching the web and found the llvm::BlockAddress class ( > http://llvm.org/doxygen/classllvm_1_1BlockAddress.html). With

I've been playing around with the new IndirectBr and BlockAddress types. I'm finding that in CodeGen, during "EliminateMostlyEmptyBlocks", BlockAddresses are not updated to point to the newly merged block if the original block was eliminated. This is causing me problems. Mind you, I'm experimenting with this using the Sparc backend, which could be the source of blame, but

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

My apologies. This problem was indeed with my changes to the backend. Next time I will more carefully examine the source of the problem. :) On Fri, Feb 26, 2010 at 12:40 PM, Marc de Kruijf <dekruijf at wisc.edu> wrote: > I've been playing around with the new IndirectBr and BlockAddress types. > I'm finding that in CodeGen, during "EliminateMostlyEmptyBlocks", >

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

Hi all, I recently updated my LLVM tree and I have a strange issue with the use of blockaddress. The LLVM file that I try to compile is [1]. I do: > llvm-as test_ba.ll > opt -O2 test_ba.bc -o test_ba_opt.bc > llc test_ba_opt.bc In r159116 (committed in 24/06/2012) I get (in the end of the .s file): .type table_closures, at object # @table_closures .section .rodata,"a",

On 9/17/2012 11:59 AM, Yiannis Tsiouris wrote: > Hi all, > > I recently updated my LLVM tree and I have a strange issue with the use > of blockaddress. The LLVM file that I try to compile is [1]. Taking the address of a block by itself has zero guarantees about whether or not that block will exist by the time the code is emitted. If the block no longer exists by the end, it gets