search for: typevalu

Displaying 8 results from an estimated 8 matches for "typevalu".

Did you mean: typeval
2010 Oct 06
1
[LLVMdev] Associating types directly with debug metadata?
...> value of that type. >> >> I agree completely. > > Ok, I will try using undefs, but do they work for aggregate types? Well, I'll see. > > However, I don't understand what is so different in my design from MDNode and MDString being values? Sure, I could make the TypeValue a subclass of MDNode, name it something like MDType, and use a tag different form "typeval", something like "metatype". Would that be better? Or should it still be a direct subclass of Value, like both MDNode and MDString are? > > I tried to carefully model my code afte...
2010 Sep 30
0
[LLVMdev] Associating types directly with debug metadata?
...thout any modifications: >> >> !21 = metadata !{ %struct.T *null, metadata !11 } > > I would recommend this approach. But that would have a hacky feeling :-) Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet. This works well enough for our purposes; I don't have any incentive to go further unless someone else needs a simi...
2010 Sep 30
3
[LLVMdev] Associating types directly with debug metadata?
On Sep 30, 2010, at 1:30 AM, Pekka Nikander wrote: >>>> Would the right starting point be to simply add an MDNode pointer to the Type class? That should be then convertible to a DIType? >>> >>> We want to avoid any Type class modification. Instead you can use pair in named metadata to match metadata with type. >>> >>> !11 = metadata !{i32
2010 Oct 05
2
[LLVMdev] Associating types directly with debug metadata?
...gt;> >>> !21 = metadata !{ typeval %struct.T, metadata !11 } >>> >>> to avoid the problem with the keyword 'type'. >>> > > Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet. Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type...
2010 Oct 06
0
[LLVMdev] Associating types directly with debug metadata?
...ust create an undef >> value of that type. > > I agree completely. Ok, I will try using undefs, but do they work for aggregate types? Well, I'll see. However, I don't understand what is so different in my design from MDNode and MDString being values? Sure, I could make the TypeValue a subclass of MDNode, name it something like MDType, and use a tag different form "typeval", something like "metatype". Would that be better? Or should it still be a direct subclass of Value, like both MDNode and MDString are? I tried to carefully model my code after MDNode...
2010 Oct 06
2
[LLVMdev] Associating types directly with debug metadata?
On Oct 5, 2010, at 11:23 PM, Nick Lewycky wrote: >> >> Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker
2023 Apr 04
5
[RFC PATCH 0/5] fstests specific MAINTAINERS file
I think I might be mad to include that many mailing lists in this patchset... As I explained in [PATCH 1/5], fstests covers more and more fs testing thing, so we always get help from fs specific mailing list, due to they learn about their features and bugs more. Besides that, some folks help to review patches (relevant with them) more often. So I'd like to bring in the similar way of
2010 Oct 06
0
[LLVMdev] Associating types directly with debug metadata?
...> !21 = metadata !{ typeval %struct.T, metadata !11 } >>>> >>>> to avoid the problem with the keyword 'type'. >>>> >> >> Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet. > > Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates th...