llvm dev - Sep 2009 - [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.

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