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

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Mon Mar 26 18:17:55 PDT 2007


           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 

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

define void @foo(%struct.s* %agg.result) {
        %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 :)


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

More information about the llvm-bugs mailing list