LLVM结构数组迭代

时间:2016-05-01 18:29:04

标签: c llvm llvm-clang llvm-ir

使用LLVM编译此代码时:

struct bar {
    int int1;
    int int2;
    char char1;
    char char2;
    char char3;
};


struct foo {
    struct bar array[16];
};


int func(struct foo *f, int num) {

    for(int i = 0; i < num; i++){
        f->array[i].int1 = 1;
        f->array[i].int2 = 2;
        f->array[i].char1 = 'a';
        f->array[i].char2 = 'b';        
        f->array[i].char3 = 'c';        
    }
    return num;
}

由于某种原因,编译器决定以奇怪的方式遍历此数组。 首先,它在结构的中间或末尾选择一个看似任意的点, 然后使用相对于任意点的immediates存储适当的值。

我发现从这个IR代码中选择了任意点:

  %scevgep = getelementptr %struct.foo* %f, i32 0, i32 0, i32 0, i32 4

其中4是char3的偏移量。

在这个例子中,int1,int2,char1,char2的存储将具有负的immediates,char3将立即为0。

似乎结构条的不同排列你得到不同的偏移但总是在结构的内部或末尾。

例如,将struct bar更改为:

struct bar {
    char char1;
    char char2;
    char char3;
    int int1;
    int int2;
};

将产生以下IR线:

  %scevgep = getelementptr %struct.foo* %f, i32 0, i32 0, i32 0, i32 3

这意味着char1,char2和char3的存储将具有负的immediates,int1将立即为0,而int2将具有正的立即。

为什么它相对于结构基础以外的点进行迭代?

1 个答案:

答案 0 :(得分:1)

Clang的最新版本不会生成您描述的getelementptr指令。它使用普通索引。它最奇怪的是生成一个版本,循环体展开两次:

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

%struct.foo = type { [16 x %struct.bar] }
%struct.bar = type { i32, i32, i8, i8, i8 }

define i32 @func(%struct.foo* nocapture %f, i32 %num) {
entry:
  %cmp25 = icmp sgt i32 %num, 0
  br i1 %cmp25, label %for.body.preheader, label %for.cond.cleanup

for.body.preheader:                               ; preds = %entry
  %xtraiter = and i32 %num, 1
  %0 = icmp eq i32 %num, 1
  br i1 %0, label %for.cond.cleanup.loopexit.unr-lcssa, label %for.body.preheader.new

for.body.preheader.new:                           ; preds = %for.body.preheader
  %unroll_iter = sub i32 %num, %xtraiter
  br label %for.body

for.cond.cleanup.loopexit.unr-lcssa.loopexit:     ; preds = %for.body
  %indvars.iv.next.1.lcssa = phi i64 [ %indvars.iv.next.1, %for.body ]
  br label %for.cond.cleanup.loopexit.unr-lcssa

for.cond.cleanup.loopexit.unr-lcssa:              ; preds = %for.cond.cleanup.loopexit.unr-lcssa.loopexit, %for.body.preheader
  %indvars.iv.unr = phi i64 [ 0, %for.body.preheader ], [ %indvars.iv.next.1.lcssa, %for.cond.cleanup.loopexit.unr-lcssa.loopexit ]
  %lcmp.mod = icmp eq i32 %xtraiter, 0
  br i1 %lcmp.mod, label %for.cond.cleanup.loopexit, label %for.body.epil.preheader

for.body.epil.preheader:                          ; preds = %for.cond.cleanup.loopexit.unr-lcssa
  br label %for.body.epil

for.body.epil:                                    ; preds = %for.body.epil.preheader
  %int1.epil = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.unr, i32 0
  store i32 1, i32* %int1.epil, align 4, !tbaa !1
  %int2.epil = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.unr, i32 1
  store i32 2, i32* %int2.epil, align 4, !tbaa !6
  %char1.epil = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.unr, i32 2
  store i8 97, i8* %char1.epil, align 4, !tbaa !7
  %char2.epil = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.unr, i32 3
  store i8 98, i8* %char2.epil, align 1, !tbaa !8
  %char3.epil = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.unr, i32 4
  store i8 99, i8* %char3.epil, align 2, !tbaa !9
  br label %for.cond.cleanup.loopexit.epilog-lcssa

for.cond.cleanup.loopexit.epilog-lcssa:           ; preds = %for.body.epil
  br label %for.cond.cleanup.loopexit

for.cond.cleanup.loopexit:                        ; preds = %for.cond.cleanup.loopexit.unr-lcssa, %for.cond.cleanup.loopexit.epilog-lcssa
  br label %for.cond.cleanup

for.cond.cleanup:                                 ; preds = %for.cond.cleanup.loopexit, %entry
  ret i32 %num

for.body:                                         ; preds = %for.body, %for.body.preheader.new
  %indvars.iv = phi i64 [ 0, %for.body.preheader.new ], [ %indvars.iv.next.1, %for.body ]
  %niter = phi i32 [ %unroll_iter, %for.body.preheader.new ], [ %niter.nsub.1, %for.body ]
  %int1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv, i32 0
  store i32 1, i32* %int1, align 4, !tbaa !1
  %int2 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv, i32 1
  store i32 2, i32* %int2, align 4, !tbaa !6
  %char1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv, i32 2
  store i8 97, i8* %char1, align 4, !tbaa !7
  %char2 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv, i32 3
  store i8 98, i8* %char2, align 1, !tbaa !8
  %char3 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv, i32 4
  store i8 99, i8* %char3, align 2, !tbaa !9
  %indvars.iv.next = or i64 %indvars.iv, 1
  %int1.1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.next, i32 0
  store i32 1, i32* %int1.1, align 4, !tbaa !1
  %int2.1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.next, i32 1
  store i32 2, i32* %int2.1, align 4, !tbaa !6
  %char1.1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.next, i32 2
  store i8 97, i8* %char1.1, align 4, !tbaa !7
  %char2.1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.next, i32 3
  store i8 98, i8* %char2.1, align 1, !tbaa !8
  %char3.1 = getelementptr inbounds %struct.foo, %struct.foo* %f, i64 0, i32 0, i64 %indvars.iv.next, i32 4
  store i8 99, i8* %char3.1, align 2, !tbaa !9
  %indvars.iv.next.1 = add nsw i64 %indvars.iv, 2
  %niter.nsub.1 = add i32 %niter, -2
  %niter.ncmp.1 = icmp eq i32 %niter.nsub.1, 0
  br i1 %niter.ncmp.1, label %for.cond.cleanup.loopexit.unr-lcssa.loopexit, label %for.body
}

如果您使用重现您看到的IR的步骤更新您的问题,我很乐意解释为什么LLVM会生成它,但我不想根据指令的名称进行猜测。