similar to: [LLVMdev] Linking opaque types

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

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 >

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

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

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

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.

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

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

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

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

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

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

Greetings everyone! I've just written two small patches. The first one allow opacifying windows when resizing ; it adds two options to resize plugin's gconf data : opacify (int, opacify percent) & opacify_non_opaque (bool, sets if non opaque windows should be opacified when resizing) The second one just add the option opacify_non_opaque to move plugin. Both patches were

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

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: