search for: llvmtypekind

Hi, The first patch fixes the implementation of umul.with.overflow on x86 which was throwing a 'Cannot yet select' error. The second patch fixes the definition of LLVMTypeKind in the C binding by syncing it with the c++ counterpart. Please review and commit if it looks ok. thanks Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090601/149fa968/...

Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenbe...

I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part

...nt LLVMAddTypeName(LLVMModuleRef M, const char *Name, LLVMTypeRef > Ty); > void LLVMDeleteTypeName(LLVMModuleRef M, const char *Name); > > @@ -198,7 +201,10 @@ void LLVMDeleteTypeName(LLVMModuleRef M, const > char *Name); > * opaque type > */ > > +/** See [llvm::LLVMTypeKind::getTypeID]. */ > LLVMTypeKind LLVMGetTypeKind(LLVMTypeRef Ty); > + > +/** See [llvm::DerivedType::refineAbstractTypeTo]. */ > void LLVMRefineAbstractType(LLVMTypeRef AbstractType, LLVMTypeRef > ConcreteType); > > /* Operations on integer types */ > @@ -546,13 +552,13 @@ L...

--- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type:

...9;d expect it to be named something like "LLVMModuleAddTypeName" or something, using NamespaceClassMethod uniformly. > Pointers are opaque, obviously. I find myself copying enums, which > is mildly scary. Copying the enums does seems scary. Is there any way around this? Is LLVMTypeKind that useful? > I'm using C strings instead of const char*, size_t tuples. This > avoids having to write things like "tmp", strlen("tmp") in C, and > is well-supported for language bindings. Nevertheless, most > languages other than C have binary-safe stri...

Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at

...Zoltan On Mon, Jun 1, 2009 at 10:57 PM, Zoltan Varga <vargaz at gmail.com> wrote: > Hi, > > The first patch fixes the implementation of umul.with.overflow on x86 > which was throwing a 'Cannot yet select' error. > The second patch fixes the definition of LLVMTypeKind in the C binding by > syncing it with the c++ counterpart. > > Please review and commit if it looks ok. > > thanks > > Zoltan > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/ll...

Hi all, I'm authoring a C interface to the LLVM IR type system. Since this is Really Quite Tedious, I would like to solicit opinions before I get too far down any paths that seem offensive. I've attached the header, where I've mapped a portion of Module and most of Type and its subclasses. This is working, and I've built ocaml bindings on top of it.[1] My intent is to