similar to: [LLVMdev] Instruciton replacement

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Instruciton replacement"

2010 Dec 15
0
[LLVMdev] The best way to cope with AllocationInst type in old code?
Hamid 2C wrote: > Hi all, > > I am working on some old code which was compiled against llvm-2.5. > Anyway, in some places I, AllocationInst is used (e.g. to ensure the > instruction's type). Even in your current documentation > (http://llvm.org/docs/ProgrammersManual.html), I found an example that > uses this instruction. > If I got it correctly, this istruction
2010 Dec 15
2
[LLVMdev] The best way to cope with AllocationInst type in old code?
Hi all, I am working on some old code which was compiled against llvm-2.5. Anyway, in some places I, AllocationInst is used (e.g. to ensure the instruction's type). Even in your current documentation (http://llvm.org/docs/ProgrammersManual.html), I found an example that uses this instruction. If I got it correctly, this istruction (AllocationInst) has been removed from llvm instruction set.
2006 Mar 15
0
[LLVMdev] RE: Port to Solaris' Sun Studio 8
Michael Smith wrote: > Well, line 364 wasn't actually what was holding me up, so it's a bad > example, but the problem's still relevant. Using cast<...>(iter), > dyn_cast<...>(iter), or isa<...>(iter) results in the error messages > mentioned below. .... > When compiling LoadValueNumbering.cpp, I get the following errors: > >
2006 Mar 14
2
[LLVMdev] Port to Solaris' Sun Studio 8
Well, line 364 wasn't actually what was holding me up, so it's a bad example, but the problem's still relevant. Using cast<...>(iter), dyn_cast<...>(iter), or isa<...>(iter) results in the error messages mentioned below. ________________________________ When compiling LoadValueNumbering.cpp, I get the following errors:
2002 Sep 16
4
[LLVMdev] another question
In the section expaining "dyn_cast" There are following lines of code: if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) { ... } I cannot understand how you take a operand, a value, and cast it into a Instruction. Can you explain it for me? Another common example is: // Loop over all of the phi nodes in a basic block BasicBlock::iterator BBI =
2002 Sep 28
0
[LLVMdev] Re: an error
dyn_cast<> will return NULL if i is not an AllocationInst object. --Vikram http://www.cs.uiuc.edu/~vadve > From: Jianzhong Liu <jliu7 at uiuc.edu> > Sender: jliu7 at cs.uiuc.edu > Date: Sat, 28 Sep 2002 17:00:04 -0500 > Subject: an error > > I keep getting a core dump error for: > > ... > const Type *opType =
2004 Mar 23
1
[LLVMdev] malloc instruction
Hi, I'm currently implementing some optimization passes for LLVM and I came across a problem. I'm new to LLVM so if this question has been asked before please kindly tell me where can I find the answer. There are 2 types of AllocationInst - Alloca and Malloc. But most of the time from the compiled byte code I can only find the Alloca statement (actually I never come across a
2010 Dec 15
1
[LLVMdev] The best way to cope with AllocationInst type in old code?
On 12/15/10 2:37 AM, Nick Lewycky wrote: > Hamid 2C wrote: >> Hi all, >> >> I am working on some old code which was compiled against llvm-2.5. >> Anyway, in some places I, AllocationInst is used (e.g. to ensure the >> instruction's type). Even in your current documentation >> (http://llvm.org/docs/ProgrammersManual.html), I found an example that >>
2006 Mar 15
0
[LLVMdev] Re: Re: Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
Chris Lattner wrote: > Here's a new snapshot of the front-end: > http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz > > This: > > 1. Fixes the inline asm problem you have above. > 2. Includes patches to make it better on Alpha's (thanks to patches by > Andrew Lenharth). > 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). > 4.
2011 May 09
0
[LLVMdev] <badref> showed up when duplicating a list of dependent instructions
Hi Chuck, > std::vector<Instruction *>::iterator p; > Instruction * pi = PREVIOUS_POSITION; > BasicBlock * pb = PREVIOUS_POSITION->getParent(); > > for(p = coll.begin(); p != coll.end(); ++p){ > Instruction * CurI = * p; > Instruction * CloneI = CurI->clone(); clone doesn't know have any magical way of knowing that it should update the instruction's
2011 May 09
2
[LLVMdev] <badref> showed up when duplicating a list of dependent instructions
I collected a sequence of LLVM instructions, want to make a copy of each and insert them into a PREVIOUS location inside the same function (all globals and locals are properly declared before the PREVIOUS location). Here is the list of instructions I want to duplicate and insert: 0 %90 = load i32* @strstart, align 4 1 %91 = add i32 %90, 2 2 %88 = load i32* @ins_h, align 4 3 %92 =
2013 Dec 04
0
[LLVMdev] DwarfDebug problems
On Tue, Dec 3, 2013 at 10:07 PM, Brandon Holt <bholt at cs.washington.edu> wrote: > Thanks for the quick response. > > I wrote some code to search “llvm.dbg.cu” for the function (right before the > failed assertion): > > if (TheCU == nullptr) { > errs() << "compile unit: " << TheCU << "\n scopeNode(" << >
2013 Dec 04
0
[LLVMdev] DwarfDebug problems
How do I find and update the lexical blocks? Is, for example, “CloneFunction” doing this in a way I can copy? I tried finding the subprogram node in “llvm.dbg.cu” and updating the function: DISubprogram s(*subprog_iter); if (s.getFunction() == F) { s.replaceFunction(NF); } But this didn’t seem to have any effect. Do I need to do something similar with every basic block or something? On Dec
2013 Dec 04
2
[LLVMdev] DwarfDebug problems
Thanks for the quick response. I wrote some code to search “llvm.dbg.cu” for the function (right before the failed assertion): if (TheCU == nullptr) { errs() << "compile unit: " << TheCU << "\n scopeNode(" << FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; auto fn =
2009 Aug 11
1
[LLVMdev] globals, modules and badref.
While adapting my JIT compiler to ToT coming from 2.5, I found this: Referencing global in another module! %3 = bitcast [8 x i8]** <badref> to i8* ; <i8*> [#uses=1]Instruction <badref> is a naked (void*) pointer. This worked on 2.5 without problem. I tried creating a GlobalVariable: external constant [8 x i8]* ; <[8 x i8]**>:<badref>
2013 Dec 04
2
[LLVMdev] DwarfDebug problems
In your transform I'd take a look at things like the individual basic blocks you're replacing and the functions you're replacing and making sure that the various lexical blocks are being changed at the same time... -eric On Tue, Dec 3, 2013 at 11:12 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Dec 3, 2013 at 10:07 PM, Brandon Holt <bholt at
2012 Nov 02
0
[LLVMdev] Instruction does not dominate all uses! <badref> ??
edA-qa mort-ora-y wrote: > I'm having trouble figuring out what the error "Instruction does not > dominate all uses!" means. I'm trying to construct a call to a function > with two parameters. The printed IR, with error, looks like this: > > define i32 @add(i32, i32) { > EntryBlock: > %2 = add i32 %0, %1 > ret i32 %2 > } > > define i32
2012 Nov 02
0
[LLVMdev] Instruction does not dominate all uses! <badref> ??
Hi edA-qa mort-ora-y, On 02/11/12 10:20, edA-qa mort-ora-y wrote: > I'm having trouble figuring out what the error "Instruction does not > dominate all uses!" means. I'm trying to construct a call to a function > with two parameters. The printed IR, with error, looks like this: > > define i32 @add(i32, i32) { > EntryBlock: > %2 = add i32 %0, %1 >
2012 Nov 02
2
[LLVMdev] Instruction does not dominate all uses! <badref> ??
Okay, I've think I understand now. By using a "Value" object (like a function call) in another instruction does nothing more than use a reference to that value. It is still my responsibility to ensure that value/reference is actually created prior to its use in the block. On 02/11/12 12:16, Nick Lewycky wrote: > edA-qa mort-ora-y wrote: >> I'm having trouble figuring
2013 Dec 04
0
[LLVMdev] DwarfDebug problems
On Tue, Dec 3, 2013 at 9:04 PM, Brandon Holt <bholt at cs.washington.edu> wrote: > In a pass I’m working on, I’ve done some manipulation of several functions, replacing them with new copies with different types, etc. > > The LLVM IR passes the verifier, but when I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent