search for: dw_tag_array_typ

..., type: !5, flags: DIFlagArtificial) This will generate the following DWARF information. DW_TAG_string_type: DW_AT_name: character(*)!1 DW_AT_string_length: 0x9b (location list) DW_AT_byte_size: 4 2.2 Fortran Array Types and Bounds In this section we refer to the DWARF tag, DW_TAG_array_type, which is used to describe Fortran arrays. However in Fortran, arrays are not types but are rather runtime data objects, a multidimensional rectangular set of scalar data of homogeneous type. An array object has dimensions (rank and corank) and extents in those dimensions. The rank and ranges of...

Hi. I searched and the closest thing I could find was this http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html Currently a known sized array looks and debugs as expected. I use llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size field. In my language arrays are always passed around with a pointer and size pair. I'd like debugging to show up as nicely instead of a pointer addr with no information about the elements. How would I do this? I don't use the C API, I output llvm-ir directly. I was hoping I c...

...positeType(tag: DW_TAG_class_type, file: !3, templateParams: !6, scope: !8) !6 = !{!7} ; The reference to @b and struct.TA.0 (renamed) that will be loaded in %a.o !7 = !DITemplateValueParameter(value: i1 (%struct.TA*)* @b) !8 = distinct !DISubprogram(unit: !2) !9 = !DICompositeType(tag: DW_TAG_array_type, identifier: "SHARED", scope: !8)

...> am quite new to this part of LLVM. > > > > 1. DICompositeType “SHARED” in a.ll is ODRed with the one in b.ll at load > > time. > > I know relatively little about LTO but I see that in a.ll, "SHARED" is > described as a DW_TAG_class_type while in b.ll it is DW_TAG_array_type. > This suggests that you have an ODR violation in your source code. > Hi Paul Thanks for pointing it out. I fixed this by making in b.ll and the same failure persists. !9 = !DICompositeType(tag: DW_TAG_class_type, file: !3, identifier: "SHARED", scope: !8) -Xin > ODR violat...

...int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4 DW_AT_encoding DW_ATE_signed <1>< 144> DW_TAG_array_type DW_AT_type <134> <2>< 149> DW_TAG_subrange_type DW_AT_type <141> DW_AT_upper_bound <141>1 [...] gcc 3/4: [...] LOCAL_SYMBOLS: [...] <2>< 66> DW_TAG...

...int DW_AT_encoding DW_ATE_signed DW_AT_byte_size 4 <1>< 141> DW_TAG_base_type DW_AT_byte_size 4 DW_AT_encoding DW_ATE_signed <1>< 144> DW_TAG_array_type DW_AT_type <134> <2>< 149> DW_TAG_subrange_type DW_AT_type <141> DW_AT_upper_bound <141>1 [...] gcc 3/4: [...] LOCAL_SYMBOLS: [...] <2>< 66> DW_TAG...

...ould be nice to use a similar scheme here. This will generate the following DWARF information. DW_TAG_string_type: DW_AT_name: character(*)!1 DW_AT_string_length: 0x9b (location list) DW_AT_byte_size: 4 2.2 Fortran Array Types and Bounds In this section we refer to the DWARF tag, DW_TAG_array_type, which is used to describe Fortran arrays. However in Fortran, arrays are not types but are rather runtime data objects, a multidimensional rectangular set of scalar data of homogeneous type. An array object has dimensions (rank and corank) and extents in those dimensions. The rank and ranges of...

...m-dev at lists.llvm.org> wrote: > > Hi. I searched and the closest thing I could find was this > http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html > > Currently a known sized array looks and debugs as expected. I use > llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size > field. In my language arrays are always passed around with a pointer and > size pair. I'd like debugging to show up as nicely instead of a pointer > addr with no information about the elements. How would I do this? I don't > use the C API, I output llvm-ir direct...

On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote: > > > > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > Hey folks, > > > > Would you all mind having a bit of a design discussion around the > feature both at the DWARF level and the LLVM implementation? It seems like > what's

...al_block Tag = 258, Count = 1, Ops = 1, Name = DW_TAG_expression Tag = 13, Count = 73880, Ops = 299110, Name = DW_TAG_member Tag = 58, Count = 1387, Ops = 4161, Name = DW_TAG_imported_module Tag = 1, Count = 2747, Ops = 21976, Name = DW_TAG_array_type Tag = 46, Count = 1341021, Ops = 12069189, Name = DW_TAG_subprogram Tag = 257, Count = 4373879, Ops = 20785065, Name = DW_TAG_arg_variable Tag = 8, Count = 2246, Ops = 6738, Name = DW_TAG_imported_declaration Tag = 53, Count = 57, Ops = 228, Nam...

Hi, I see things like this. What does it mean? Is it documented somewhere? Thanks. ; preds = %for.body https://llvm.org/docs/LangRef.html ; <label>:91: ; preds = %88 %92 = load i8**, i8*** @glob_complete_word.matches, align 8, !dbg !99798 %93 = load i32, i32* @glob_complete_word.ind, align 4, !dbg !99799 %94 = sext i32 %93 to i64, !dbg !99798

In r219010, I merged integer and string fields into a single header field. By reducing the number of metadata operands used in debug info, this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and I've concluded that they will be insufficient. Instead, I'd like to implement a more aggressive plan,