similar to: [LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction

On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi David, I'm seeing an assertion failure when passing this node > > !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t", i32 > 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ] > [fn_t] [line 5, size 0, align 0, offset 0] [from ]

Hi Eric, On 10/04/13 00:20, Eric Christopher wrote: > On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote: >> Hi David, I'm seeing an assertion failure when passing this node >> >> !{i32 786454, metadata <badref>, metadata <badref>, metadata !"fn_t", i32 >> 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ;

On Wed, Apr 10, 2013 at 4:48 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Eric, > > On 10/04/13 00:20, Eric Christopher wrote: >> >> On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote: >>> >>> Hi David, I'm seeing an assertion failure when passing this node >>> >>> !{i32 786454, metadata

On Mon, Apr 15, 2013 at 6:20 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Wed, Apr 10, 2013 at 4:48 AM, Duncan Sands <baldrick at free.fr> wrote: >> Hi Eric, >> >> On 10/04/13 00:20, Eric Christopher wrote: >>> >>> On Tue, Apr 9, 2013 at 1:53 AM, Duncan Sands <baldrick at free.fr> wrote: >>>> >>>> Hi David,

On Tue, Apr 16, 2013 at 3:04 PM, Eric Christopher <echristo at gmail.com> wrote: > On Mon, Apr 15, 2013 at 6:20 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Wed, Apr 10, 2013 at 4:48 AM, Duncan Sands <baldrick at free.fr> wrote: >>> Hi Eric, >>> >>> On 10/04/13 00:20, Eric Christopher wrote: >>>> >>>> On Tue,

On Tue, Apr 16, 2013 at 4:54 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Apr 16, 2013 at 3:04 PM, Eric Christopher <echristo at gmail.com> wrote: >> On Mon, Apr 15, 2013 at 6:20 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> On Wed, Apr 10, 2013 at 4:48 AM, Duncan Sands <baldrick at free.fr> wrote: >>>> Hi Eric,

Hi Eric, >> But then we still don't emit anything about the function (& neither does GCC). >> So make it a member function (so we are forced to emit the declaration >> even without complicating the example by having to add a definition >> (which by necessity cannot use the typedef))... and then we see that >> the subprogram description doesn't refer to a

Have I correctly inferred below, how I build IR and debug info for a function type and a function (value), in particular, how to supply the names of the formal parameters? To create a function in llvm IR and give names to its formal parameters, I must: 1. Build a LLVMTypeRef for the type of each formal and the function result. 2. Build a function type using LLVMFunctionType, from the results of

On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren

On Mon, Jul 21, 2014 at 3:48 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 3:41 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie

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 =

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

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 =

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

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

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

That was likely type information and should mostly be fixed up. It's still not lazily loaded, but is going to be ridiculously smaller now. -eric On Fri Jan 10 2014 at 12:11:52 AM, Sean Silva <chisophugis at gmail.com> wrote: > This Summer I was working on LTO and Rafael mentioned to me that debug > info is not lazy loaded, which was the cause for the insane resource usage > I

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

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 @eval_expr() { EntryBlock: ret i32 <badref> } Instruction does not dominate

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 build of LLVM/Clang from Git mirror): > Assertion failed: (TheCU && "Unable to find