similar to: Question concerning llvm::BlockAddress class

Displaying 20 results from an estimated 1000 matches similar to: "Question concerning llvm::BlockAddress class"

2018 Apr 16
0
Question concerning llvm::BlockAddress class
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
2019 Jan 28
2
Create a BlockAddress array from LLVM Pass
Hi Good day. For the following function local static constant array: static const __attribute__((used)) __attribute__((section("data"))) void *codetable[] = { &&RETURN, &&INCREMENT, &&DECREMENT, &&DOUBLE, &&SWAPWORD}; I have the following in the LLVM IR. @sampleCode.codetable = internal global [5 x i8*] [i8* blockaddress(@sampleCode, %19), i8*
2019 Jan 29
2
[cfe-dev] Create a BlockAddress array from LLVM Pass
Sorry for emailing both group. As I will have a constant array of BlockAddress, what type I should use in Constant Array for its ArrayType declaration? I am creating the list in following way: unsigned int nBr = fit->second.size(); llvm::Constant *listBA[nBr]; unsigned int Idx = 0; for (std::set<llvm::BasicBlock *>::iterator it = fit->second.begin(); it != fit->second.end(); ++it)
2010 Mar 15
2
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2011 Aug 01
0
[LLVMdev] SwitchInst::addCase with BlockAddress
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 =
2010 Mar 15
0
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2011 Jul 31
3
[LLVMdev] SwitchInst::addCase with BlockAddress
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);
2017 Jul 29
2
Storing "blockaddress(@function, %block)" in a global variable?
Hi, The LangRef warns that "blockaddress(@function, %block)" has a limited and target-dependent applicability: https://llvm.org/docs/LangRef.html#addresses-of-basic-blocks But I wanted very much to save addresses of blocks in a global variable and so I did: % cat cond.c void foo(long *a) { if (a) *a = 0; } % clang -O1 -c cond.c -fsanitize-coverage=inline-8bit-counters,pc-table -S
2010 Mar 15
0
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2010 Dec 11
3
[LLVMdev] indirectbr/blockaddress question
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
2010 Mar 15
1
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2020 Feb 28
2
Is BlockAddress always correct ?
Hi I use BlockAddress to get the address of BasicBlock , and I use GlobalVariable 's getInitializer() to pass the address of BasicBlock to the global variable of my own program and then I print it out. But , I found that BlockAddress is not always correct. For example, some function's rsp (stack pointer) or other register is maintained by caller, so it would be like:
2010 Mar 15
3
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2010 Mar 15
0
[LLVMdev] LLVM tries to remove labels used in blockaddress()
On Mar 15, 2010, at 10:07 AM, Bob Wilson wrote: >>> An earlier revision simply generated asm-code, where the appropriate label was missing, thus causing gcc to fail when i wanted to compile the asm-file. >> >> Here is a slightly reduced testcase: >> >> define i8* @test1() nounwind { >> entry: >> ret i8* blockaddress(@test_fun, %test_label) >> }
2010 Mar 15
3
[LLVMdev] LLVM tries to remove labels used in blockaddress()
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
2010 Dec 12
0
[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
2010 Feb 26
2
[LLVMdev] BlockAddress is a "User"
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
2019 Aug 08
2
in an IR pass: access the instruction pointer/BB address
Hi, I looked through the documentation and source and am unable to find a way: in an IR pass on basic blocks for (auto &F : M) for (auto &BB : F) { .... } I want to access the current address of the basic block. It does not need to be the exact address of the BB, a few instructions down of that BB is fine as well. basically the same that I could do with an "leaq
2012 Sep 17
2
[LLVMdev] Label address (taken with blockaddress) not exported to .s
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",
2012 Sep 17
0
[LLVMdev] Label address (taken with blockaddress) not exported to .s
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