Julien Lerouge
2009-Sep-11 00:55 UTC
[LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
Hello folks, I have a small piece of C code written like this: typedef struct { char a; int b; int c; } foo; foo myFoo[5] = {{0}}; With llvm-gcc 2.5, I get the following IR: %struct.foo = type { i8, i32, i32 } @myFoo = global [5 x %struct.foo] zeroinitializer, align 32 With the current 2.6, I get this: %0 = type { i8, [11 x i8] } %struct.foo = type { i8, i32, i32 } @myFoo = global [5 x %0] zeroinitializer, align 32 Is there any reason for the change ? It is weird that in the end, with 2.6 myFoo doesn't have the [5 x %struct.foo]* type. Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com
Hello Julien, I think the reason for the change was because there is processor context information stored in the type in 2.6. The reason it's there is to support multicore JIT architecture. --Sam ----- Original Message ----> From: Julien Lerouge <jlerouge at apple.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thursday, September 10, 2009 7:55:37 PM > Subject: [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6. > > Hello folks, > > I have a small piece of C code written like this: > > typedef struct { > char a; > int b; > int c; > } foo; > > foo myFoo[5] = {{0}}; > > With llvm-gcc 2.5, I get the following IR: > > %struct.foo = type { i8, i32, i32 } > @myFoo = global [5 x %struct.foo] zeroinitializer, align 32 > > With the current 2.6, I get this: > > %0 = type { i8, [11 x i8] } > %struct.foo = type { i8, i32, i32 } > @myFoo = global [5 x %0] zeroinitializer, align 32 > > Is there any reason for the change ? It is weird that in the end, with > 2.6 myFoo doesn't have the [5 x %struct.foo]* type. > > Thanks, > Julien > > -- > Julien Lerouge > PGP Key Id: 0xB1964A62 > PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 > PGP Public Key from: keyserver.pgp.com > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sep 10, 2009, at 11:10 PM, Samuel Crow wrote:> I think the reason for the change was because there is processor > context information stored in the type in 2.6. The reason it's > there is to support multicore JIT architecture.Interesting. FWIW, clang-cc -emit-llvm also produces something similar but not quite the same:>> From: Julien Lerouge <jlerouge at apple.com> >> I have a small piece of C code written like this: >> >> typedef struct { >> char a; >> int b; >> int c; >> } foo; >> >> foo myFoo[5] = {{0}};%0 = type <{ %1, %struct.anon, %struct.anon, %struct.anon, %struct.anon }> %1 = type { i8, [11 x i8] } %struct.anon = type { i8, i32, i32 } @myFoo = global %0 zeroinitializer, align 4 ; <%0*> [#uses=0] So that [11 x i8] is somehow for multicore JIT? It produces this even if the architecture is set to blackfin. This seems pretty weird and non-intuitive to me too. I would be interested in learning about the rationale. Ultimately clang is storing 3 bytes extra in the lead element, llvm-gcc has 3*5=15. Ray
Hi Julien Lerouge,> I have a small piece of C code written like this: > > typedef struct { > char a; > int b; > int c; > } foo;> %0 = type { i8, [11 x i8] }I guess it wants to initialize the alignment padding to zero. Anyway, it sure looks like a bug/inefficiency. Please open a bugreport. Ciao, Duncan.
Julien Lerouge
2009-Sep-11 07:43 UTC
[LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
On Fri, Sep 11, 2009 at 09:22:59AM +0200, Duncan Sands wrote:> I guess it wants to initialize the alignment padding to zero. Anyway, > it sure looks like a bug/inefficiency. Please open a bugreport.Alright, filed http://llvm.org/bugs/show_bug.cgi?id=4947 Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Key from: keyserver.pgp.com
Maybe Matching Threads
- [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
- [LLVMdev] AnalysisUsage & Call Graph SCC Pass Manager
- [LLVMdev] Problem in External/SPEC/CFP2000/177.mesa/Makefile ?
- [LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
- [LLVMdev] Pre pr4572 lvm-gcc building/working revision needed