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