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