[LLVMbugs] [Bug 1278] NEW: struct layout suboptimality

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=1278

           Summary: struct layout suboptimality
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


On darwin ppc32, this code:

struct s {
  double d1;
  int s1;
};

struct s foo(void) {
  struct s S = {1.1, 2};
  return S;
}

Compiles "s" to type { double, i32, [4 x i8] }.  There are two problems with this:

1. [4 x i8] can be int, which would be more efficient since it is just tail padding.  This tail padding exists 
because the struct has 8-byte alignment, but llvm thinks both double/int have 4 byte alignment.  If the 
padding bytes weren't made explicit, the struct would be too small.

2. CopyAggregate copies by the llvm fields even if there are no source-level fields that correspond to 
them.

The end result of this is that the example compiles into:

define void @foo(%struct.s* %agg.result) {
entry:
        %tmp20 = getelementptr %struct.s* %agg.result, i32 0, i32 0             ; <double*> [#uses=1]
        store double 1.100000e+00, double* %tmp20
        %tmp23 = getelementptr %struct.s* %agg.result, i32 0, i32 1             ; <i32*> [#uses=1]
        store i32 2, i32* %tmp23
        %tmp28 = getelementptr %struct.s* %agg.result, i32 0, i32 2, i32 0              ; <i8*> [#uses=1]
        store i8 0, i8* %tmp28
        %tmp31 = getelementptr %struct.s* %agg.result, i32 0, i32 2, i32 1              ; <i8*> [#uses=1]
        store i8 0, i8* %tmp31
        %tmp34 = getelementptr %struct.s* %agg.result, i32 0, i32 2, i32 2              ; <i8*> [#uses=1]
        store i8 0, i8* %tmp34
        %tmp37 = getelementptr %struct.s* %agg.result, i32 0, i32 2, i32 3              ; <i8*> [#uses=1]
        store i8 0, i8* %tmp37
        ret void
}

Note that the 4 byte stores are completely dead.  If #1 were solved at least we'd have a single dead 
word store :)

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.