search for: typeval

...said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them looks like this: case Type::PointerTyID: // POINTER: [pointee type] Code = bitc::TYPE_CODE_POINTER; TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- >getElementType())); The code to read them look like this: case bitc::TYPE_CODE_POINTER: // POINTER: [pointee type] if (Record.size() < 1) return Error("Invalid POINTER type record"); ResultTy = P...

...gt; > !21 = metadata !{ %struct.T, metadata !11 } > > But I don't know if that would be valid syntax... I thought about that more, and I think the "right" way would be to have a syntax like !21 = metadata !{ type %struct.T, metadata !11 } or perhaps !21 = metadata !{ typeval %struct.T, metadata !11 } to avoid the problem with the keyword 'type'. But to be able to do that, should apparently be possible to represent types as first class values. That in turn would apparently require a new Type::TypeID? Would that be worth doing? Apparently we can fake with ou...

This also implements support for String (Mountable, _) parameters. --- daemon/Makefile.am | 4 ++++ daemon/blkid.c | 6 ------ daemon/blkid.ml | 40 ++++++++++++++++++++++++++++++++++++++++ daemon/blkid.mli | 19 +++++++++++++++++++ daemon/mountable.ml | 43 +++++++++++++++++++++++++++++++++++++++++++ daemon/mountable.mli | 34

...!11 } >> >> But I don't know if that would be valid syntax... > > I thought about that more, and I think the "right" way would be to have a syntax like > > !21 = metadata !{ type %struct.T, metadata !11 } > > or perhaps > > !21 = metadata !{ typeval %struct.T, metadata !11 } > > to avoid the problem with the keyword 'type'. > > But to be able to do that, should apparently be possible to represent types as first class values. That in turn would apparently require a new Type::TypeID? > > Would that be worth doing?...

On Nov 24, 2007, at 7:47 PM, Christopher Lamb wrote: > > On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > >> On Wed, 21 Nov 2007, Christopher Lamb wrote: >>>> Unlike alignment and volatility, I think that the address space >>>> qualifier >>>> should be represented explicitly in the type system. The >>>> reason for this

>> We would need to access the LLVM debug metadata type information directly from LLVM types. It looks like the current clang and llvm-gcc don't support such an association, nor appears the LLVM itself do. > > True. I am curious how do you want to use this association ? Thanks for you advice below, Devang. We are using LLVM type definitions + debug metadata to interpret binary

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

...said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them looks like this: case Type::PointerTyID: // POINTER: [pointee type] Code = bitc::TYPE_CODE_POINTER; TypeVals.push_back(VE.getTypeID(cast<PointerType>(T)- >getElementType())); The code to read them look like this: case bitc::TYPE_CODE_POINTER: // POINTER: [pointee type] if (Record.size() < 1) return Error("Invalid POINTER type record"); ResultTy = P...

...a to match metadata with type. >>>> >> >> I thought about that more, and I think the "right" way would be to have a syntax like >> >> !21 = metadata !{ type %struct.T, metadata !11 } >> >> or perhaps >> >> !21 = metadata !{ typeval %struct.T, metadata !11 } >> >> to avoid the problem with the keyword 'type'. >> >> Would that be worth doing? Apparently we can fake with our need, and use a null pointer instead. Technically, that would be wrong, but would work with the current code without any...

On Nov 21, 2007, at 6:22 PM, Chris Lattner wrote: > On Wed, 21 Nov 2007, Christopher Lamb wrote: >>> Unlike alignment and volatility, I think that the address space >>> qualifier >>> should be represented explicitly in the type system. The reason >>> for this > >> I've come across a hitch. Store instructions do not reference the

>>> I thought about that more, and I think the "right" way would be to have a syntax like >>> >>> !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....

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

This change allows parts of the daemon to be written in the OCaml programming language. I am using the ‘Main Program in C’ method along with ‘-output-obj’ to create an object file from the OCaml code / runtime, as described here: https://caml.inria.fr/pub/docs/manual-ocaml/intfc.html Furthermore, change the generator to allow individual APIs to be implemented in OCaml. This is picked by

Pekka Nikander wrote: >>>> I thought about that more, and I think the "right" way would be to have a syntax like >>>> >>>> !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...

...EmitTypeGenerate(OS, ArgType->getValueAsDef("ElTy")); + OS << ", " << ArgType->getValueAsInt("NumElts") << ")"; + } else { + OS << "Type::getPrimitiveType("; + OS << ArgType->getValueAsString("TypeVal") << ")"; + } +} + /// RecordListComparator - Provide a determinstic comparator for lists of /// records. namespace { @@ -176,6 +192,43 @@ OS << "#endif\n\n"; } +void IntrinsicEmitter::EmitGenerator(const std::vector<CodeGenIntrinsic> &Ints,...

Move the list_filesystems API into the daemon, reimplementing it in OCaml. Since this API makes many other API calls, it runs a lot faster in the daemon. --- daemon/Makefile.am | 2 + daemon/ldm.ml | 3 + daemon/ldm.mli | 2 + daemon/listfs.ml | 156 +++++++++++++++++++++++++++++ daemon/listfs.mli | 19 ++++ daemon/lvm.ml | 3 +

...yID: { + const UnionType *ST = cast<UnionType>(T); + // UNION: [eltty x N] + Code = bitc::TYPE_CODE_UNION; + // Output all of the element types. + for (StructType::element_iterator I = ST->element_begin(), + E = ST->element_end(); I != E; ++I) + TypeVals.push_back(VE.getTypeID(*I)); + AbbrevToUse = UnionAbbrev; + break; + } Please rename ST -> UT and use the right iterator type. I didn't look closely at the C bindings. If you eliminate empty unions they should get a bit simpler. Otherwise the patch looks like a fine start....

This patch adds a UnionType to DerivedTypes.h. It also adds code to the bitcode reader / writer and the assembly parser for the new type, as well as a tiny .ll test file in test/Assembler. It does not contain any code related to code generation or type layout - I wanted to see if this much was acceptable before I proceeded any further. Unlike my previous patch, in which the Union type was

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK: