[llvm-bugs] [Bug 46433] New: Inliner loses the original alignment for passing by value argument

[via llvm-bugs]

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

            Bug ID: 46433
           Summary: Inliner loses the original alignment for passing by
                    value argument
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Interprocedural Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: igor.breger at intel.com
                CC: llvm-bugs at lists.llvm.org

Looks like the passing of the struct by value, to be inlined into a memcpy with
align 1 source pointer casted to i8*, to be sroa’d, loses the original
alignment. In this case target sensitive to  alignment generate sub-optimal
code.


C code example
        typedef struct
        {    
                int* ptr1;
                int* ptr2;
                int part;
        } LabelsType ;


        int call1(LabelsType _labels, int tileNum) { 
                return _labels.ptr1[tileNum];
        }

        int test(LabelsType * t)
        {
                return call1(*t, 6);
        }


clang -O0 -S -emit-llvm

%struct.LabelsType = type { i32*, i32*, i32 }

define dso_local i32 @call1(%struct.LabelsType* byval(%struct.LabelsType) align
8 %_labels, i32 %tileNum) {
entry:
  %tileNum.addr = alloca i32, align 4
  store i32 %tileNum, i32* %tileNum.addr, align 4
  %ptr1 = getelementptr inbounds %struct.LabelsType, %struct.LabelsType*
%_labels, i32 0, i32 0
                                                                               
                                # originally we have align 8
  %0 = load i32*, i32** %ptr1, align 8                              

  %1 = load i32, i32* %tileNum.addr, align 4
  %idxprom = sext i32 %1 to i64
  %arrayidx = getelementptr inbounds i32, i32* %0, i64 %idxprom
  %2 = load i32, i32* %arrayidx, align 4
  ret i32 %2
}

define dso_local i32 @test(%struct.LabelsType* %t) {
entry:
  %t.addr = alloca %struct.LabelsType*, align 8
  store %struct.LabelsType* %t, %struct.LabelsType** %t.addr, align 8
  %0 = load %struct.LabelsType*, %struct.LabelsType** %t.addr, align 8
  %call = call i32 @call1(%struct.LabelsType* byval(%struct.LabelsType) align 8
%0, i32 6)
  ret i32 %call
}

opt -S --inline -instcombine -sroa -instcombine   <opt0 file>

define dso_local i32 @call1(%struct.LabelsType* byval(%struct.LabelsType) align
8 %_labels, i32 %tileNum) {
entry:
  %ptr1 = getelementptr inbounds %struct.LabelsType, %struct.LabelsType*
%_labels, i64 0, i32 0
  %0 = load i32*, i32** %ptr1, align 8
  %idxprom = sext i32 %tileNum to i64
  %arrayidx = getelementptr inbounds i32, i32* %0, i64 %idxprom
  %1 = load i32, i32* %arrayidx, align 4
  ret i32 %1
}

define dso_local i32 @test(%struct.LabelsType* %t) {
entry:
  %.sroa.0.0..cast.sroa_idx = getelementptr inbounds %struct.LabelsType,
%struct.LabelsType* %t, i64 0, i32 0
                                                                               
                                      # we got align 1  
  %.sroa.0.0.copyload = load i32*, i32** %.sroa.0.0..cast.sroa_idx, align 1
  %arrayidx.i = getelementptr inbounds i32, i32* %.sroa.0.0.copyload, i64 6
  %0 = load i32, i32* %arrayidx.i, align 4
  ret i32 %0
}


For similar code (manual inlining) 

int test1(LabelsType * t)
{
   return t->ptr1[6];
}

We got align 8 load  ( %0 = load i32*, i32** %ptr1, align 8 ):

define dso_local i32 @test1(%struct.LabelsType* nocapture readonly %t)
local_unnamed_addr #0 {
entry:
  %ptr1 = getelementptr inbounds %struct.LabelsType, %struct.LabelsType* %t,
i64 0, i32 0
  %0 = load i32*, i32** %ptr1, align 8, !tbaa !2
  %arrayidx = getelementptr inbounds i32, i32* %0, i64 6
  %1 = load i32, i32* %arrayidx, align 4, !tbaa !8
  ret i32 %1
}

-- 
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/20200624/3e58d54b/attachment.html>