GCC -O3优化下循环索引类型为何影响GIMPLE向量常量（不影响汇编）

测试源码 #

#include <stdio.h>
#include <stdlib.h>

#define N 256

typedef struct arc {
   int num;
} arc_t;

typedef double cost_t;

typedef struct  basket {
    arc_t *a;
    cost_t cost;

} BASKET;

static BASKET basket[N];
static BASKET *perm[N];

int main() {
     __asm__ ("########");
     int j;
   
    for ( j = 0; j < N; j++)
    {
        perm[j] = &(basket[j]) ;
    }
    __asm__ ("########");
    
    printf("%d\n",perm[1]->a->num);

    return 0;
}

编译命令 #

使用以下命令生成中间文件：

gcc -O3 p.c -fdump-tree-vect-details -fopt-info-vec -S -mavx2

两种索引类型的中间代码对比 #

情况1：j为int类型时的中间代码 #

<bb 2> [local count: 10737416]:
  __asm__ __volatile__("########");
  vect_cst__13 = { 8, 8, 8, 8, 8, 8, 8, 8 };
  vect_cst__22 = { 16, 16, 16, 16, 16, 16, 16, 16 };
  _27 = (long unsigned int) &basket;
  vect_cst__28 = {_27, _27, _27, _27};

情况2：j为long类型时的中间代码 #

<bb 2> [local count: 10737416]:
  __asm__ __volatile__("########");
  vect_cst__14 = { 4, 4, 4, 4 };
  vect_cst__19 = { 16, 16, 16, 16 };
  _23 = (long unsigned int) &basket;
  vect_cst__24 = {_23, _23, _23, _23};

疑问点 #

• 推测差异源于int和long的大小不同，但j只是数组索引，为何其类型会影响中间代码？两种情况下basket[j]的前四个地址完全一致（使用GCC 10.3.0）。
• 怀疑前端编译器应用了不同优化，该从何处查找相关信息？GCC是如何分析结构体数组的？

内容的提问来源于stack exchange，提问作者Daisy G