similar to: [LLVMdev] Brain dump on type merging

On Thu, Dec 4, 2014 at 1:18 AM, Hal Finkel <hfinkel at anl.gov> wrote: > +1 -- We don't need types on pointers -- they don't convey any information > to the optimizer. FWIW, it would not surprise me if the elimination of all > of the unnecessary pointer bitcasts produces measurable compile-time > savings. Indeed. I'm actually interested in looking at this if no

On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote: > Type names don't have meaning.  If you want this not to happen, you > can generate a different opaque type for each type in your language to > prevent merging. Hi Andrew, Why create opaque types to avoid something that should be taken from granted (in a said "type-safe" representation)? 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.

On Wed, Feb 18, 2015 at 6:58 AM, Colin LeMahieu <colinl at codeaurora.org> wrote: > It might help after adding explicit types where needed and before adding > the opaque pointer type, to change all pointers to a single type in the > existing type system, i8* could work or maybe a weird type that would shake > out any issues like i99*. > I'm not sure this would help

On Tue, Feb 17, 2015 at 10:47 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Feb 17, 2015 at 10:27 PM, Chris Lattner <clattner at apple.com> > wrote: > >> On Feb 17, 2015, at 1:58 PM, Chandler Carruth <chandlerc at gmail.com> >> wrote: >> > I'm not actually worried about this change though Chris, at least >> w.r.t.

I've got a call instruction: call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26) nounwind %4 and %9 are both (stripped) opaque structs. InlineFunction() does not inline this because

Sorry, I was being an idiot and was trying to link the wrong file type. Sigh. Now I have a problem where I merge two modules each containing the same struct, one opaque and one defined, and it's not merging the two consistently. I have two, let's say %"StructA" = type opaque %"StructB" = type opaque in one module, and in the other: %"StructA" = type { i8 }

On Feb 7, 2012, at 1:29 AM, Fraser Cormack wrote: > > Sorry, I was being an idiot and was trying to link the wrong file type. Sigh. > > Now I have a problem where I merge two modules each containing the same > struct, one opaque and one defined, and it's not merging the two > consistently. I have two, let's say > > %"StructA" = type opaque >

On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > I've got a call instruction: > call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26)

This is a nominative vs. structural type system issue. You assume the type system to be nominative, while LLVM uses a structural one. In this type system Foo and Bar is the same type. There are various pros and cons for both systems. For LLVM it seems appropriate to use structural typing as it only uses types to calculate sizes, offsets and alignments. Btw arguably this is not a type safety

On Sat, Jun 13, 2009 at 9:44 PM, John McCall<rjmccall at apple.com> wrote: > On Jun 13, 2009, at 3:54 AM, Wesley W. Terpstra wrote: > Currently I just represent %c as i8*. I assume that this can have > consequences in terms of aliasing. I tried opaque*, but llvm-as didn't > like that. Is there any way to better represent the type %c to LLVM? > > I assume this is for

Following a(n apparently) failed attempt to upgrade a BT102, the phone is now brain-dead. Although it still has enough smarts to get a dhcp address and try to download the firmware and config, it never gets past the blue screen, nor will it respond to pings or port 80. Short of sending it back to Grandstream, is there any way to recover the phone? TIA Bruce Komito High Sierra Networks, Inc.

Hi, (sorry if the CC's are inappropriate, they seemed relevant based on a git log of IRMover.cpp) I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One part of that is doing inlining of operators. For that I'm using bitcode pre-generated using clang. The current code uses a single LLVMContext & Orc to generate the code. That largely workes well. But inlining

> On Mar 23, 2018, at 16:11, Andres Freund via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > (sorry if the CC's are inappropriate, they seemed relevant based on a > git log of IRMover.cpp) > > I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One > part of that is doing inlining of operators. For that I'm using bitcode

Hi, On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: > > The second approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf

> -----Original Message----- > From: Philip Reames [mailto:listmail at philipreames.com] > Sent: Friday, August 28, 2015 9:38 AM > To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm- > dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers > <andya at

Eli, Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing… though it then seems to turn right around and do exactly that by inserting the bitcast. ;-) (That does come from the linker.) That the linker 'works

I'm building a StructType without a body using StructType *StructType::create(LLVMContext &Context, StringRef Name); and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. If I create a StructType using StructType * StructType ::create(LLVMContext

Good afternoon! I'm trying to write an LLVM codegen for a Standard ML compiler (MLton). So far things seem to match up quite nicely, but I have hit two sticking points. I'm hoping LLVM experts might know how to handle these two cases better. 1: In ML we have some types that are actually one of several possible types. Expressed in C this might be thought of as a union. The codegen only

2011/7/9 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> It looks like we need to have opaque function types? Or we need to defer >> emission of some types until we've finished the translation unit. > > We were deferring this before, no? We could not produce a function type > taking an opaque type. Once it go resolved we would need to revisit the >