[llvm-bugs] [Bug 45188] New: opt ignores alignment

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=45188

            Bug ID: 45188
           Summary: opt ignores alignment
           Product: libraries
           Version: 9.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm at henning-thielemann.de
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

I have a nested struct, where the inner struct contains an i64 and thus
requires 8-byte alignment.

$ cat alignment.ll
target triple = "x86_64-unknown-linux-gnu"

%struct = type { i1, { float, i64 } }

define %struct* @initialize(i8*) {
  %ptr = bitcast i8* %0 to %struct*
  %ptrBool = getelementptr %struct, %struct* %ptr, i32 0, i32 0
  store i1 1, i1* %ptrBool
  %ptrFloat = getelementptr %struct, %struct* %ptr, i32 0, i32 1, i32 0
  store float 42.0, float* %ptrFloat
  %ptrInt64 = getelementptr %struct, %struct* %ptr, i32 0, i32 1, i32 1
  store i64 123456789, i64* %ptrInt64
  ret %struct* %ptr
}

Without optimization the field offsets are computed correctly:

$ llc-9 <alignment.ll
        .text
        .file   "<stdin>"
        .globl  initialize              # -- Begin function initialize
        .p2align        4, 0x90
        .type   initialize, at function
initialize:                             # @initialize
        .cfi_startproc
# %bb.0:
        movq    %rdi, %rax
        movb    $1, (%rdi)
        movl    $1109917696, 8(%rdi)    # imm = 0x42280000
        movq    $123456789, 16(%rdi)    # imm = 0x75BCD15
        retq
.Lfunc_end0:
        .size   initialize, .Lfunc_end0-initialize
        .cfi_endproc
                                        # -- End function

        .section        ".note.GNU-stack","", at progbits

With optimization the struct becomes surprisingly more compact:

$ opt-9 -O1 <alignment.ll | llc-9
        .text
        .file   "<stdin>"
        .globl  initialize              # -- Begin function initialize
        .p2align        4, 0x90
        .type   initialize, at function
initialize:                             # @initialize
# %bb.0:
        movq    %rdi, %rax
        movb    $1, (%rdi)
        movl    $1109917696, 4(%rdi)    # imm = 0x42280000
        movq    $123456789, 8(%rdi)     # imm = 0x75BCD15
        retq
.Lfunc_end0:
        .size   initialize, .Lfunc_end0-initialize
                                        # -- End function

        .section        ".note.GNU-stack","", at progbits


It looks like opt flattens the struct.

$ opt-9 -O1 <alignment.ll | llvm-dis-9
; ModuleID = '<stdin>'
source_filename = "<stdin>"
target triple = "x86_64-unknown-linux-gnu"

%struct = type { i1, { float, i64 } }

; Function Attrs: nofree norecurse nounwind writeonly
define %struct* @initialize(i8*) local_unnamed_addr #0 {
  %ptr = bitcast i8* %0 to %struct*
  %ptrBool = bitcast i8* %0 to i1*
  store i1 true, i1* %ptrBool, align 1
  %ptrFloat = getelementptr i8, i8* %0, i64 4
  %2 = bitcast i8* %ptrFloat to float*
  store float 4.200000e+01, float* %2, align 4
  %ptrInt64 = getelementptr i8, i8* %0, i64 8
  %3 = bitcast i8* %ptrInt64 to i64*
  store i64 123456789, i64* %3, align 4
  ret %struct* %ptr
}

attributes #0 = { nofree norecurse nounwind writeonly }


It seems that bitcasting from i8* enables opt to do wrong simplifications.
If I replace i8* by {}* then opt leaves the struct layout as is.

Is this a bug or a feature?
Do I need to give opt more information in order to prevent it from such wrong
simplifications?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200312/ff14ef3e/attachment-0001.html>