llvm dev - Oct 2010 - [LLVMdev] Structure memory layout

Hi Renato,

Firstly, I have been removing target specific information from struct type on
bitcode.
Target specific information are type size, type alignment, merged bitfields and
so on.

For example

  1 struct test {
  2   char a:3;
  3   char b:4;
  4   char c:3;
  5   char d:2;
  6 };
  7
  8 struct test vm = {1, 2, 3, 1};
  9
 10 int main(void)
 11 {
 12   int a;
 13   vm.d = 1;
 14 }
 
Above source code is compiled using cross arm-llvm-gcc as following.

  1 ; ModuleID = './temp2.c'
  2 target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
  3 target triple = "armv5-none-linux-gnueabi"
  4
  5 %0 = type { i8, i8 }
  6 %struct.test = type <{ i8, i8 }>
  7
  8 @vm = global %0 { i8 17, i8 11 }                  ; <%0*> [#uses=1]
  9
 10 define arm_aapcscc i32 @main() nounwind {
 11 entry:
 12   %retval = alloca i32                            ; <i32*> [#uses=1]
 13   %a = alloca i32                                 ; <i32*> [#uses=0]
 14   %"alloca point" = bitcast i32 0 to i32          ; <i32>
[#uses=0]
 15   %0 = load i8* getelementptr inbounds (%struct.test* bitcast (%0* @vm to
%struct.test*), i32 0, i32 1), align 1 ; <i8> [#uses=1]
 16   %1 = and i8 %0, -25                             ; <i8> [#uses=1]
 17   %2 = or i8 %1, 8                                ; <i8> [#uses=1]
 18   store i8 %2, i8* getelementptr inbounds (%struct.test* bitcast (%0* @vm to
%struct.test*), i32 0, i32 1), align 1
 19   br label %return
 20
 21 return:                                           ; preds = %entry
 22   %retval1 = load i32* %retval                    ; <i32> [#uses=1]
 23   ret i32 %retval1
 24 }

In line5-6, bitfields for struct type is merged.
Merging bitfields is affected by type alignment and type size.
(type alignment  and type size are target dependent information.)
I have been convert above bitcode to more target independent bitcode as
following.

  1 ; ModuleID = './temp2.c'
  2 target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
  3 target triple = "armv5-none-linux-gnueabi"
  4
  5 %0 = type { i3, i4, i3, i2 }
  6 %struct.test = type <{ i3, i4, i3, i2 }>
  7
  8 @vm = global %0 { i3 1, i4 2, i3 3, i2 1 }        ; <%0*> [#uses=1]
  9
 10 define arm_aapcscc i32 @main() nounwind {
 11 entry:
 12   %retval = alloca i32                            ; <i32*> [#uses=1]
 13   %a = alloca i32                                 ; <i32*> [#uses=0]
 14   %"alloca point" = bitcast i32 0 to i32          ; <i32>
[#uses=0]
 15   call void @llvm.setelement.i2(i8* bitcast (i4* getelementptr
(%struct.test* bitcast (%0* @vm to %struct.test*), i32 1, i32 1) to i8*), i2 1)
 16   br label %return
 17
 18 return:                                           ; preds = %entry
 19   %retval1 = load i32* %retval                    ; <i32> [#uses=1]
 20   ret i32 %retval1
 21 }
 22
 23 declare void @llvm.setelement.i2(i8*, i2) nounwind

I have been trying to maintain shape of struct type within original source code
on bitcode.
This type become concrete according to each target on llc pass
and above "setelement" intrinsic function is also concrete on llc
pass.
(Until now, I have been considering compilation pass from llvm-gcc to llc.
Currently, I am working on llc pass.)

As you can see above, I have been trying to make more target independent struct
type, not completely.

Secondly, I also finded union type's target dependent problems through long
double type on core-utils package.

File isnan.c
 28 # define DOUBLE long double
...
 66 #define NWORDS \
 67   ((sizeof (DOUBLE) + sizeof (unsigned int) - 1) / sizeof (unsigned int))
 68 typedef union { DOUBLE value; unsigned int word[NWORDS]; } memory_double;

Because floating point data type isn't allowed to have bitwise operation,
above isnan function converts long double type to unsigned int array whether or
not to know "not a number".

I think that both above statements and refered union types problems on your
answer are source codes which don't consider portability for multi-platform.
I have been focusing on target independent bitcode about source codes which
consider portability for multi-platform, not above statements.
(Target dependent memory layout  for struct type is generated on source codes
which consider portability for multi-platform,)

My subject in my team makes more target independent bitcode, not completely.
In addition to memory layout for struct type, I have been considering several
target dependent inforamtion on current bitcode.
If I have a chance, I would like to discuss the information with llvm
developers. :)

I really appreciate your answer.

Thanks,
Jin-Gu Kang

Hi Jin Gu Kang
>    5 %0 = type { i3, i4, i3, i2 }
each of the above struct fields occupies 1 byte.  If you were hoping that an
i3 field would occupy only 3 bits then I am sorry, it doesn't work that way.

Ciao,

Duncan.

On 19 October 2010 13:28, Duncan Sands <baldrick at free.fr>
wrote:
> Hi Jin Gu Kang
>
>>    5 %0 = type { i3, i4, i3, i2 }
>
> each of the above struct fields occupies 1 byte.  If you were hoping that
an
> i3 field would occupy only 3 bits then I am sorry, it doesn't work that
way.
Hi Duncan,

I'm not sure he meant that, but you are right, the container type is
lost in the process.

Jim,

Consider the examples:

struct testChar { char a:3;  char b:4;  char c:3;  char d:2; };
struct testInt { int a:3;  int b:4;  int c:3;  int d:2; };

In your IR, both would be represented by:

%0 = type { i3, i4, i3, i2 }

But the first will actually be a 2-byte structure (as you can see on
LLVM's IR) and the second a 2/4/8-byte structure (depending on the
target). How would you distinguish them?

If LLVM types had alignment, you could represent as:

%Char = type { i3 align 1, i4 align 1, i3 align 1, i2 align 1 }
%Int = type { i3 align 4, i4 align 4, i3 align 4, i2 align 4 }

and even

%Short = type { i3 align 2, i4 align 2, i3 align 2, i2 align 2 }

for short fields. That would tell the codegen to fit as many i** into
the group of fields with the same alignment. It'd also help with
implementing zero sized bit-fields:

struct zero { int :0; short i; }
to:
%zero = type { i16 } align 32;

Type alignment would also help to remove the burden on carrying
alignment information throughout the life of a variable, as you can
only (and have to) emit it on instructions.

But wait, a word of caution, I haven't thought through properly to
assure you it's the best way, not even if it's safe. Others on the
list might know better.

cheers,
--renato