别名分析和_restrict关键字 - C

别名分析如何与关键字__restrict和__noalias一起使用？它是否认为它们是没有锯齿的证据？或者根据指针简单计算自己的结果？别名分析和_restrict关键字 - C

望着LLVM的别名分析，在许多紧密循环做负载-binop店序列的结果，下面的瓶颈看到：即使输入和输出指针用__restrict，别名分析仍然充分标假设它们为'MayAlias'，并使循环结束时的商店依赖于循环中的所有负载。

例如

void _BitwiseOr_(unsigned char * __restrict * __restrict src1Addr, unsigned char * __restrict * __restrict src2Addr, unsigned char * __restrict * __restrict destAddr, unsigned int width) { 
     uchar16 * __restrict src1 = (uchar16 * __restrict) *src1Addr; 
     uchar16 * __restrict src2 = (uchar16 * __restrict) *src2Addr; 
     uchar16 * __restrict dest = (uchar16 * __restrict) *destAddr; 


     for (unsigned int i = 0; i < width; i += 4) { 
     *dest++ = *src1++ | *src2++; 
     *dest++ = *src1++ | *src2++; 
     *dest++ = *src1++ | *src2++; 
     *dest++ = *src1++ | *src2++; 
     } 
    }

。

define void @_BitwiseOr_(i8** noalias nocapture readonly %src1Addr, i8** noalias nocapture readonly %src2Addr, i8** noalias nocapture readonly %destAddr, i32 %width) local_unnamed_addr #0 { 
entry: 
    %0 = bitcast i8** %src1Addr to <16 x i8>** 
    %1 = load <16 x i8>*, <16 x i8>** %0, align 4, !tbaa !2 
    %2 = bitcast i8** %src2Addr to <16 x i8>** 
    %3 = load <16 x i8>*, <16 x i8>** %2, align 4, !tbaa !2  
    %4 = bitcast i8** %destAddr to <16 x i8>** 
    %5 = load <16 x i8>*, <16 x i8>** %4, align 4, !tbaa !2   
    %6 = load <16 x i8>, <16 x i8>* %1, align 8, !tbaa !6 
    %7 = load <16 x i8>, <16 x i8>* %3, align 8, !tbaa !6 
    %or = or <16 x i8> %7, %6 
    store <16 x i8> %or, <16 x i8>* %5, align 8, !tbaa !6 
    ret void 
}

别名分析回答，唯一的NO别名之间：

i8** src1addr - i8** src2addr, 
i8** src1addr - i8** destaddr, 
i8** src2addr - i8** destaddr, 
i8** destaddr - i8** destaddr, 
i8** src1addr - i8** src1addr, 
i8** src2addr - i8** src2addr

为何不使用__restrict关键字的“好处”？是否有可能使其工作？

以上是通过用铿锵编译：

-cc1 -S -disable-free -main-file-name file.cpp -mllvm -disable-block-placement -funroll-loops -mllvm -unroll-allow-partial -mllvm -tail-merge-size=71 -mllvm -tail-dup-size=70 -fmath-errno -v -gcodeview -dwarf-column-info -coverage-file file.s -O3 -Wall -Werror=implicit-function-declaration -std=c++14 -fdeprecated-macro -fno-dwarf-directory-asm -ferror-limit 19 -fmessage-length 0 -ffreestanding -fallow-half-arguments-and-returns -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -mllvm -no-phi-elim-live-out-early-exit -mllvm -use-cfl-aa=anders -mllvm -use-cfl-aa-in-codegen=anders -mllvm -debug -mllvm -da-delinearize -mllvm -mllvm -enable-tbaa -mllvm -enable-scoped-noalias -mllvm -evaluate-aa-metadata -mllvm -print-all-alias-modref-info

来源

2016-09-19 eternalStudent

你还期待什么其他的“别名”？你提供的列表似乎涵盖了所有的输入？ – Joky

我还应该期待％1 - ％3，％3 - ％5 aka src1 - src2等（检查更新后的源代码） – eternalStudent

您需要阅读在C标准的规则。

“限制”指针当然可以是别名。只是这在某些情况下会产生未定义的行为，所以它们是别名，但编译器完全可以忽略它。

您还需要知道，“restrict”只影响从“restrict”指针派生的指针，而不是从相同的“restrict”指针派生的指针。例如，如果p是一个“限制”指针并且你调用f（p），那么这个调用可以将p存储到任何静态或全局指针变量中。因此，如果在调用之后读取这样的指针变量，编译器不知道它是否从限制指针派生，并且如果它是从p派生的，则应用别名规则。

来源

2016-09-19 15:36:06 gnasher729

但是根据C标准：它不会直接指定何时出现混叠并且不可能。但是，它声明一个类型的对象应该只有一个引用有一个相关类型的访问，才能访问其存储的值。那么，显式地，那些类型与列表不一致的访问对不能被别名访问。以混叠方式重申这些规则，忽略限定符（常量，易失性和限制）时兼容的类型为！这就是为什么我的查询仍然存在... – eternalStudent

别名分析和_restrict关键字 - C

回答

相关问题