search for: typevals

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

>>> 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 524307, metadata !1, metadata !"T", metadata !1, i32 2, i64 32, i64

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

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

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

Pekka Nikander 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 performs type reductions, and

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

>>>> We want to avoid any Type class modification. Instead you can use pair in named metadata 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

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

>>> 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 performs type reductions, and I don't understand

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

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

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: