LLVM 3.6: Bad IR generation

I’m getting some weird results in the text of my LLVM-IR when compiling using version 3.6 with the -g option. For a simple c function (in a file func.c, shown below)

void test_func(unsigned int * dIn, unsigned int * dOut) {
unsigned int idx = 0;
for (idx = 0; idx < 100; idx++) {
dOut[idx] = dIn[idx];
}
return;
}

and the compile command shown below

/path/to/clang -target x86_64 -v -g -S -emit-llvm -o func.ll func.c

The LLVM IR in the resultant .ll file (in part included below) contains strings with a lot of unusual and unnecessary characters, including a lot of null characters ‘\000’. This seams to be in the part of the LLVM IR related to the Dwarf information, and goes away with the removal of the -g option from the command line. I’ve tried this with a number of different optimization levels and target architectures with the same results. Any help or explanation for the odd strings is greatly appreciated.

; Function Attrs: nounwind readnone
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1

attributes #0 = { nounwind uwtable “less-precise-fpmad”=“false” “no-frame-pointer-elim”=“true” “no-frame-pointer-elim-non-leaf” “no-infs-fp-math”=“false” “no-nans-fp-math”=“false” “stack-protector-buffer-size”=“8” “unsafe-fp-math”=“false” “use-soft-float”=“false” }
attributes #1 = { nounwind readnone }

!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!10, !11}
!llvm.ident = !{!12}

!0 = !{!“0x11\0012\00clang version 3.6.0 (tags/RELEASE_360/final)\000\00\000\00\001”, !1, !2, !2, !3, !2, !2} ; [ DW_TAG_compile_unit ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c] [DW_LANG_C99]
!1 = !{!“ocl_kern1.c”, !“/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat”}
!2 = !{}
!3 = !{!4}
!4 = !{!“0x2e\00test_func\00test_func\00\002\000\001\000\000\00256\000\002”, !1, !5, !6, null, void (i32*, i32*)* @test_func, null, null, !2} ; [ DW_TAG_subprogram ] [line 2] [def] [test_func]
!5 = !{!“0x29”, !1} ; [ DW_TAG_file_type ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!6 = !{!“0x15\00\000\000\000\000\000\000”, null, null, null, !7, null, null, null} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
!7 = !{null, !8, !8}
!8 = !{!“0xf\00\000\0064\0064\000\000”, null, null, !9} ; [ DW_TAG_pointer_type ] [line 0, size 64, align 64, offset 0] [from unsigned int]
!9 = !{!“0x24\00unsigned int\000\0032\0032\000\000\007”, null, null} ; [ DW_TAG_base_type ] [unsigned int] [line 0, size 32, align 32, offset 0, enc DW_ATE_unsigned]
!10 = !{i32 2, !“Dwarf Version”, i32 4}
!11 = !{i32 2, !“Debug Info Version”, i32 2}
!12 = !{!“clang version 3.6.0 (tags/RELEASE_360/final)”}
!13 = !{!“0x101\00dIn\0016777218\000”, !4, !5, !8} ; [ DW_TAG_arg_variable ] [dIn] [line 2]
!14 = !{!“0x102”} ; [ DW_TAG_expression ]
!15 = !MDLocation(line: 2, column: 31, scope: !4)
!16 = !{!“0x101\00dOut\0033554434\000”, !4, !5, !8} ; [ DW_TAG_arg_variable ] [dOut] [line 2]
!17 = !MDLocation(line: 2, column: 51, scope: !4)
!18 = !{!“0x100\00idx\003\000”, !4, !5, !9} ; [ DW_TAG_auto_variable ] [idx] [line 3]
!19 = !MDLocation(line: 3, column: 17, scope: !4)
!20 = !MDLocation(line: 5, column: 9, scope: !21)
!21 = !{!“0xb\005\004\000”, !1, !4} ; [ DW_TAG_lexical_block ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!22 = !MDLocation(line: 5, column: 18, scope: !23)
!23 = !{!“0xb\002”, !1, !24} ; [ DW_TAG_lexical_block ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!24 = !{!“0xb\001”, !1, !25} ; [ DW_TAG_lexical_block ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!25 = !{!“0xb\005\004\001”, !1, !21} ; [ DW_TAG_lexical_block ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!26 = !MDLocation(line: 5, column: 4, scope: !21)
!27 = !MDLocation(line: 6, column: 23, scope: !28)
!28 = !{!“0xb\005\0036\002”, !1, !25} ; [ DW_TAG_lexical_block ] [/home/james/workspace/Libraries/opencl/coge_ocl/trunk/test/dat/ocl_kern1.c]
!29 = !MDLocation(line: 6, column: 19, scope: !28)
!30 = !MDLocation(line: 6, column: 12, scope: !28)
!31 = !MDLocation(line: 6, column: 7, scope: !28)
!32 = !MDLocation(line: 7, column: 4, scope: !28)
!33 = !MDLocation(line: 5, column: 29, scope: !25)
!34 = !MDLocation(line: 5, column: 4, scope: !25)
!35 = !MDLocation(line: 9, column: 4, scope: !4)

James Brock

I’m getting some weird results in the text of my LLVM-IR when compiling
using version 3.6 with the -g option. For a simple c function (in a file
func.c, shown below)

void test_func(unsigned int * dIn, unsigned int * dOut) {
   unsigned int idx = 0;
   for (idx = 0; idx < 100; idx++) {
      dOut[idx] = dIn[idx];
   }
   return;
}

and the compile command shown below

/path/to/clang -target x86_64 -v -g -S -emit-llvm -o func.ll func.c

The LLVM IR in the resultant .ll file (in part included below) contains
strings with a lot of unusual and unnecessary characters, including a lot
of null characters ‘\000’. This seams to be in the part of the LLVM IR
related to the Dwarf information, and goes away with the removal of the -g
option from the command line. I’ve tried this with a number of different
optimization levels and target architectures with the same results. Any
help or explanation for the odd strings is greatly appreciated.

That's by design:

http://llvm.org/docs/SourceLevelDebugging.html#id10

"Most of the string and integer fields in descriptors are packed into a
single, null-separated mdstring. "