similar to: Getting a BasicBlock address

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);

Hi, I'm writing a pass that implements a jump table with an array of blockaddress and an indirectbr instruction. It get a blockaddress in the array (via getelementptr and an index) and then jump to this basicblock via the indirectbr. I tried to compile several libraries to test my pass and the run their test-suite. It works fine with, for e.g, libTomCrypt (in -O0,1,2,3). With GMP or

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

With Debug mode, it shows the assert error: Assertion failed: (I != BlockLiveness.end() && "Predecessor not found"), function calculateLocalLiveness, file lib/CodeGen/StackColoring.cpp, line 782. 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'busybox/archival/libarchive/decompress_bunzip2.c'. 4. Running

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

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

Hello all, I have written a pass, which replaces condition branchinst using indirectBr to obfuscate program. The origin IR is as the following: br i1 %1, label %2, label %3 And the transformed IR is as the follwoing: %4 = select i1 %1, i8* blockaddress(@func, %2), i8* blockaddress(@func, %3) indirectbr i8* %4, [label %2, label %3] The pass's core function is as the

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]

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

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

Hello, I'm currently writing a function pass for LLVM and face the following problem. I want to store the address of a BasicBlock (or the label, as LLVM refers to it) in a local variable (AllocaInst). Later on I intend to indirectly branch to this address by "dereferencing" the variable. Is this possible? I tried creating an instance of AllocaInst but I'm not quite sure which

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

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

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

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

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

Is there a way to save a reference to a Basic Block that gets all fixed up in the linker, so that you can branch to it during execution? (Or maybe just a better way to do what I'm trying to do?) In my old-school BASIC compiler that I'm writing with LLVM, for each GOSUB, I keep a map of an integer ID and a pointer to the basic block following the GOSUB to return to. Then, when a BASIC

Hi Rasha, > for(rit=Result.begin();rit!=Result.end();++rit) > { > Value* Address= BlockAddress::get (*rit); > > IndirectBrInst *IBI = IndirectBrInst::Create(Address, Result.size(),i->getTerminator() ); > IBI->addDestination((*rit)); > } This would be creating a block looking something like: [ Do stuff ] indirectbr i8*