Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction"
2013 Apr 09
0
[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 ]
2013 Apr 10
2
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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>} ;
2013 Apr 16
0
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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
2013 Apr 16
2
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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,
2013 Apr 16
0
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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,
2013 Apr 17
2
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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,
2013 Apr 17
0
[LLVMdev] Passing DW_TAG_typedef as the type to DIBuilder's createFunction
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
2015 Feb 19
4
[LLVMdev] Parameter names in IR and debug info
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
2014 Jul 21
2
[LLVMdev] LTO type uniquing: ODR assertion failure
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
2014 Jul 21
4
[LLVMdev] LTO type uniquing: ODR assertion failure
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
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 =
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
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 =
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
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
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
2014 Jan 10
3
[LLVMdev] Bitcode parsing performance
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
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
2012 Nov 02
4
[LLVMdev] Instruction does not dominate all uses! <badref> ??
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
2013 Dec 04
2
[LLVMdev] DwarfDebug problems
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