search for: typevalu

...> 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...

...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...

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

...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...

...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...

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

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

...> !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...