similar to: [LLVMdev] Linking opaque types

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 >

On Mon, Jul 25, 2011 at 8:52 AM, Anton Lokhmotov <Anton.Lokhmotov at arm.com>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

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

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

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) > ==

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

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

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.

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

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

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, http://www.llvm.org/docs/ProgrammersManual.html#BuildRecType suggests us to define recursive types via opaque and refine. Since LLVM has structural types, %rt = type { %rt* } and %rt1 = type { %rt* } should be same structurally. I tested the following code, %rt = type { %rt* } %rt1 = type { %rt* } define i32 @main() nounwind { entry: %0 = alloca %rt ;

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

Hello LLVM, I'm playing with a new ISD::OPAQUE instruction to make hoisting first class and eliminate a lot of tweaky flag setting/checking around opaque constants. It's going well for the IR and x86, but I now I need to sort out details for all the other targets. To start, can someone please advise on the AAarch64 equivalent of these X86 patterns? // Opaque values become mov immediate

On Thu, Nov 11, 2010 at 8:28 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Hi all, > > http://www.llvm.org/docs/ProgrammersManual.html#BuildRecType suggests > us to define recursive types via opaque and refine. Since LLVM has > structural types, %rt = type { %rt* } and %rt1 = type { %rt* } should > be same structurally. I tested the following code, > > %rt =

Hello all, I'm writing a backend for our scriptlanguage compiler and I'm currently writing an IR module for the runtime library that contains some support routines called by generated code. The IR module contains calls to "malloc", which depend on the size of "size_t". Since I don't know the target when writing the IR module for the runtime library, I

According to the Assembly language reference: "In LLVM, opaque types can eventually be resolved to any type (not just a structure type)." But the only way I can think of to do so is to give it a type name, then later redeclare the name. But that gives an error: %TO = type opaque %TF = type i32 ( %TO* ) %TO = type %TF gives: $ llvm-as types1.ll llvm-as: types1.ll:3:1: error:

Hello, I'm trying to translate part of Java code in LLVM code. I have some problems with the "opaque type", I think because I did not understand how to use. So, the java code is: int[] ai; .... ai = new int[1]; I am using LLVM API in this way: //I create a pointer of Opaque type, because I don't know yet the array size! OpaqueType* ot = OpaqueType::get(); AllocaInst*

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