解决由NVCC编译优化所产生的Bug

本文主要是介绍解决由NVCC编译优化所产生的Bug，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Bug描述

在测量如下一个简单的核函数的执行时间的时候，发现测量的时间和循环的次数完全无关，觉得很奇怪，因为循环的次数已经很大了，不管我再怎么提升循环次数，这么大的计算量，不可能保持时间的恒定。

__global__ void setRowReadRow(int * out)
{unsigned int idx=threadIdx.y*blockDim.x+threadIdx.x;for(unsigned int l0=0; l0<65536; l0++)for(unsigned int l1=0; l1<65536; l1++)for(unsigned int l2=0; l2<65536; l2++)for(unsigned int l3=0; l3<65536; l3++)for(unsigned int m=0; m<65536; m++){out[idx] +=  m  ;}
}

于是去查看该Kernel的PTX代码，发现该函数主体只有一条ret指令，用于函数返回，没有任何计算过程:

.visible .entry setRowReadRow(int*)(.param .u64 setRowReadRow(int*)_param_0
)
{ret;}

这就解释得通为什么执行时间不变了，于是尝试调小循环次数，只保留变量m这一层嵌套，此时PTX代码如下：

.visible .entry setRowReadRow(int*)(.param .u64 setRowReadRow(int*)_param_0
)
{ld.param.u64    %rd1, [setRowReadRow(int*)_param_0];cvta.to.global.u64      %rd2, %rd1;mov.u32         %r1, %tid.y;mov.u32         %r2, %ntid.x;mov.u32         %r3, %tid.x;mad.lo.s32      %r4, %r1, %r2, %r3;mul.wide.u32    %rd3, %r4, 4;add.s64         %rd4, %rd2, %rd3;ld.global.u32   %r5, [%rd4];add.s32         %r6, %r5, 2147450880;st.global.u32   [%rd4], %r6;ret;}

这里不解释每条指令的具体含义了，可以用GPT等大模型帮忙翻译一下，重点解释这两条指令：

        add.s32         %r6, %r5, 2147450880;st.global.u32   [%rd4], %r6;

%r5保存的是out[idx]的原始值，%rd4保存的是out[idx]在内存中的地址，所以这两条指令的意思就是out[idx]加上2147450880的值再存回去。

因为这部分代码只保留了m变量所在的那一层循环，分析可得，Kernel函数得到的结果就是把out[idx]的值再加上（0+1+2+3+…+65535)=2147450880。

很显然，编译器帮我们做了优化，把65536次循环加法变成了一次加法指令，再加上英伟达官方论坛的解答可以大致推测出，循环次数过多导致PTX代码只有一条ret指令的原因是编译器在做优化时，把循环的加法拿出去计算，导致了溢出了所以产生了不可预期的错误。

但是测试的时候发现把加法改成乘法后不会产生ret错误，分析ptx是因为对于乘法没有做这方面的优化，老老实实按照循环嵌套写的PTX代码，所以此时虽然out[idx]的计算会出现溢出，但是并不影响程序的运行。加法由于编译器会对循环优化，所以出现PTX的异常。

这篇关于解决由NVCC编译优化所产生的Bug的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---