similar to: [LLVMdev] Linking opaque types

On Jul 25, 2011, at 8:52 AM, Anton Lokhmotov wrote: > There is an issue with representing opaque types in LLVM IR modules: if two > modules are using the same opaque type (which is only going to be > specialised at some later stage), it is only identified by its name. But > the current module linker "resolves" this as if there is a name clash, and > one of that opaque

On Mon, Jul 25, 2011 at 9:36 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 25, 2011, at 8:52 AM, Anton Lokhmotov wrote: > > There is an issue with representing opaque types in LLVM IR modules: if > two > > modules are using the same opaque type (which is only going to be > > specialised at some later stage), it is only identified by its name. But >

There is an issue with representing opaque types in LLVM IR modules: if two modules are using the same opaque type (which is only going to be specialised at some later stage), it is only identified by its name. But the current module linker "resolves" this as if there is a name clash, and one of that opaque types is renamed. It contradicts an intuitively expected identifier behaviour

On Mon, Jul 25, 2011 at 11:16 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 25, 2011, at 10:58 PM, Talin wrote: > > To handle the fact that types do not (and can not, at least as long as we >> intend to support obscure languages like "C" :) have linkage, the the linker >> uses a "best effort" approach. It attempts to merge types and

On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 8:11 AM, Talin wrote: > > >> If that's true, then it means that we're back to the case where every type >> has to be fully defined down to the leaf level. >> >> >> I'm not sure what you mean. LLVM is perfectly fine with opaque structs

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

On Dec 20, 2011, at 12:11 PM, Stepan Dyatkovskiy wrote: > Is it legal to substitute non struct type instead of opaque type? > > For example: > ; 1.ll > declare void @F(i32*) > > ; 2.ll > %T1 = type opaque > declare void @F(%T1*) > > Is it normal to replace T1 with i32 here? Yes, the linker will do this, because it is forced to break type safety to link up the

2009/9/15 Carlos Sánchez de La Lama <carlos.delalama at urjc.es>: > Hi all, > > I am creating a function and trying to call it using the LLVM API. It > seems that whenever the function type includes an opaque-typed > parameter, the CallInst::Create call causes an assert: > > Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) > ==

Is it legal to substitute non struct type instead of opaque type? For example: ; 1.ll declare void @F(i32*) ; 2.ll %T1 = type opaque declare void @F(%T1*) Is it normal to replace T1 with i32 here? If yes. Will the next types are isomorphic?: %T1 = type opaque { i32, %T1* } { i32, i32* } -Stepan.

I'm looking at and running: test/Regression/Assembler/2005-05-05-OpaqueUndefValues.ll which says: ; RUN: llvm-as < %s | llvm-dis | llvm-as %t = type opaque %x = global %t undef Why is this valid? Shouldn't the assembler reject it (it doesn't)? How can a global variable be defined as opaque? What's it size? Does this just indicate that %x is some "unknown

Hi all, I am creating a function and trying to call it using the LLVM API. It seems that whenever the function type includes an opaque-typed parameter, the CallInst::Create call causes an assert: Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType()) && "Calling a function with a bad signature!"), function init, file

On Jul 25, 2011, at 10:58 PM, Talin wrote: > To handle the fact that types do not (and can not, at least as long as we intend to support obscure languages like "C" :) have linkage, the the linker uses a "best effort" approach. It attempts to merge types and rewrite IR to use the merged types where it can, but it doesn't make any guarantees. > > I want to add an

In my project I have a group of foreign types (C++ classes) that I want to use, but don't want to represent as structs within LLVM. For example, for each field in each C++ class I have a setter and getter function that I'd like to use. The setters and getters are "extern C" functions to avoid problems with C++'s name mangling. After going over the documentation it

Could someone please commit the attached patches? /* Approved by: - Anton Korobeynikov: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049849.html - Micah Villmow: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049848.html - David Neto: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-May/049705.html */ Many thanks, Anton. -----Original Message----- From: Anton Lokhmotov

OK. So if we have two modules with the same function name. This functions may not be isomorphic. For example, we can link this files, but the function types are not isomorphic: ; 1.ll %T1 = type opaque declare i32 @foo(%T1*) ; 2.ll define i32 @foo(i32* %v) {...something...} But at the same time we should not map next two functions (PR11627): ; 3.ll declare i32 @foo(i16* %v) ; 4.ll define

On Mar 21, 2011, at 1:59 PM, Zhang, Chihong wrote: > Hi Chris, > > It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make

Hi Chris, It is important for embedded/mobile computation to have efficient fp16 support, otherwise those users will suffer from the merging problem with their local LLVM with native fp16 type they add (locally). So we should either add full fp16 support as a basic floating point type or enhance the LLVM infrastructure to make floating point type as scalable as int type. -Chihong -----Original

The problem is that we use the ordering private, global, constant and local, and this is the same ordering that is used on Apple as well. As we already have OpenCL binaries out in public, making the change is problematic as we want to keep backward compatibility at all costs. Thanks, Micah > -----Original Message----- > From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] > Sent:

I have an iPad Air. Nice kit and good battery life but experience has shown the iPad is just a little too opaque and network dependent for my taste. I was wondering if there existed a similarly sized/robust tablet that can run CentOS-6/7 that anyone would recommend? I am looking from something that I can take on international trips that I can scrub on a regular basis. But, I also desire the

On Jul 27, 2011, at 12:41 AM, Talin wrote: > What do you mean "the linker fails"? Type mismatches should not cause the linker to fail. In any case, this example should link, please provide a minimal example of two .ll files that repros what you're seeing with llvm-link. Thanks, > > It's llvm-ld that asserts here: > > Assertion failed: (N < NumContainedTys