[llvm-commits] JIT: Emitting a debug location after an instruction

[Jeffrey Yasskin]

No problem. Thanks for working on this!

On Tue, Aug 24, 2010 at 11:58 AM, nicolas geoffray
<nicolas.geoffray at gmail.com> wrote:
> You are right. My changes would not work (the test I had was too simple).
> So I should probably hook that up with the GC. Sounds fun!
> Thanks Jeffrey for the explanations.
> Nicolas
>
> On Tue, Aug 24, 2010 at 4:08 AM, Jeffrey Yasskin <jyasskin at google.com>
> wrote:
>>
>> On Mon, Aug 23, 2010 at 9:37 PM, nicolas geoffray
>> <nicolas.geoffray at gmail.com> wrote:
>> >
>> >
>> > On Mon, Aug 23, 2010 at 8:57 PM, Jeffrey Yasskin <jyasskin at google.com>
>> > wrote:
>> >>
>> >> I'm not sure processDebugLoc does what you need it to, even with your
>> >> changes. It only records an address when the DebugLoc changes, and
>> >> that's not guaranteed to happen exactly on the call
>> >> MachineInstruction. (Unless you've done something to ensure it does?)
>> >
>> > Each call instruction and only call instructions have metadata
>> > associated to
>> > it. So I am sure emitting the debug location after emitting the call
>> > instructions work for my case.
>>
>> A CallInst in the IR expands to several MachineInstructions, all of
>> which have the same DebugLoc (and which may be rearranged/interleaved
>> with other DebugLoc'ed MIs by the SelectionDAG (ScheduleDAG?)). For
>> example, the following IR:
>>
>> @.str = private constant [12 x i8] c"Hello World\00" ; <[12 x i8]*>
>> [#uses=1]
>>
>> define i32 @main() nounwind {
>> entry:
>>  %call = tail call i32 @puts(i8* getelementptr inbounds ([12 x i8]*
>> @.str, i32 0, i32 0)) nounwind, !dbg !6 ; <i32> [#uses=0]
>>  ret i32 0, !dbg !8
>> }
>>
>> declare i32 @puts(i8* nocapture) nounwind
>>
>> !llvm.dbg.sp = !{!0}
>>
>> !0 = metadata !{i32 524334, i32 0, metadata !1, metadata !"main",
>> metadata !"main", metadata !"main", metadata !1, i32 2, metadata !3,
>> i1 false, i1 true, i32 0, i32 0, null, i1 false, i1 false, null} ; [
>> DW_TAG_subprogram ]
>> !1 = metadata !{i32 524329, metadata !"test.c", metadata
>> !"/Users/jyasskin/tmp", metadata !2} ; [ DW_TAG_file_type ]
>> !2 = metadata !{i32 524305, i32 0, i32 12, metadata !"test.c",
>> metadata !"/Users/jyasskin/tmp", metadata !"clang 2.8", i1 true, i1
>> true, metadata !"", i32 0} ; [ DW_TAG_compile_unit ]
>> !3 = metadata !{i32 524309, metadata !1, metadata !"", metadata !1,
>> i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !4, i32 0, null} ; [
>> DW_TAG_subroutine_type ]
>> !4 = metadata !{metadata !5}
>> !5 = metadata !{i32 524324, metadata !1, metadata !"int", metadata !1,
>> i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ]
>> !6 = metadata !{i32 3, i32 3, metadata !7, null}
>> !7 = metadata !{i32 524299, metadata !0, i32 2, i32 12} ; [
>> DW_TAG_lexical_block ]
>> !8 = metadata !{i32 4, i32 1, metadata !7, null}
>>
>>
>> Produces the following MachineFunction:
>>
>> BB#0: derived from LLVM BB %entry
>>        %ESP<def> = SUB32ri8 %ESP, 12, %EFLAGS<imp-def,dead>;
>> dbg:test.c:3:3
>>        MOV32mi %ESP, 1, %reg0, 0, %reg0, <ga:@.str>; mem:ST4[Stack]
>> dbg:test.c:3:3
>>        CALLpcrel32 <ga:@puts>, %EAX<imp-def,dead>, %ESP<imp-use>, ...;
>> dbg:test.c:3:3
>>        %EAX<def> = MOV32r0 %EFLAGS<imp-def,dead>
>>        %ESP<def> = ADD32ri8 %ESP, 12, %EFLAGS<imp-def,dead>;
>> dbg:test.c:4:1
>>        RET %EAX<imp-use,kill>; dbg:test.c:4:1
>>
>> and saves addresses in processDebugLoc at the following
>> MachineInstructions:
>>
>>  %ESP<def> = SUB32ri8 %ESP, 12, %EFLAGS<imp-def,dead>; dbg:test.c:3:3
>>  %ESP<def> = ADD32ri8 %ESP, 12, %EFLAGS<imp-def,dead>; dbg:test.c:4:1
>>
>> That is, not the call instruction. So, I'm not sure why this is
>> working for you...
>>
>> >> Do you have a unit test that shows this works in all cases?
>> >
>> > Not sure about the "all cases", but at least it is working as intended
>> > for
>> > me and these hooks (emitting before or after) were already present
>> > before my
>> > changes.
>> >
>> >>
>> >> Mapping return addresses to metadata seems like more of a job for the
>> >> GC system, but that's not implemented for the JIT, so I can't very
>> >> well say to use it instead. :-/
>> >
>> > Indeed, doing it in the GC system would also work, but the changes would
>> > be
>> > way less straightforward than this simple change in the JITemitter.
>> > Nicolas
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >
>> >
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>