blocks|key|2443530|text|是的，如果你使用完全优化的方式编译，现代的编译器会使用SSE2自动向量化。即使在-O2，-O3的gcc也能做到这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2443531|即使在-O1或-Os上，编译器也会使用SIMD加载/存储指令来复制或初始化比整数寄存器更宽的结构或其他对象。这并不是真正意义上的自动向量化；它更像是他们针对固定大小小块的默认内建memset+/+memcpy策略的一部分。但它确实利用并要求支持SIMD指令。|2443532|2443533|对于x86-64，SSE2是基线/非可选的，因此在面向x86-64时，编译器可以始终使用SSE1/SSE2指令。较新的指令集(SSE4、AVX、AVX2、AVX512和非sets，如BMI2、popcnt等)必须手动启用，以告诉编译器可以编写不能在旧CPU上运行的代码。或者让它生成多个版本的代码并在运行时进行选择，但这会带来额外的开销，并且只有对于更大的函数才是值得的。|offset|length|style|BOLD|2443534|-msse+-msse2+-mfpmath=sse+已经是x86-64的默认设置，但不是32位i386的默认设置。一些32位调用约定在x87寄存器中返回fp值，因此使用SSE/SSE2进行计算，然后必须存储/重新加载结果才能在x87+st(0)中获得结果，这可能会很不方便。对于-mfpmath=sse，更聪明的编译器可能仍然会使用x87进行计算，以生成FP返回值。|CODE|2443535|在32位x86上，默认情况下-msse2可能不会打开，这取决于编译器的配置方式。如果您使用32位是因为您的目标CPU太旧以至于不能运行64位代码，那么您可能需要确保禁用它，或者只禁用-msse。|2443536|针对您正在编译的CPU进行二进制优化的最佳方法是-O3+-march=native+-mfpmath=sse**，，并使用链接时间优化%2B配置文件引导优化**。(gcc+-fprofile-generate+/在一些测试数据上运行/+gcc+-fprofile-use)。|2443537|如果编译器选择使用新指令，则使用-march=native会生成可能无法在早期CPU上运行的二进制文件。剖面导引优化对gcc非常有帮助:没有它，它永远不会展开循环。但使用PGO，它知道哪些循环经常运行/进行大量迭代，即哪些循环是“热门”的，值得在代码大小上花费更多。链接时间优化允许跨文件的内联/恒定传播。如果你的C%2B%2B有很多不是在头文件中实际定义的小函数，这是非常有用的。|2443538|2443539|有关查看编译器输出并理解它的更多信息，请参阅+。|2443540|以下是适用于x86-64的+的一些具体示例。龙箭也有针对其他几种架构的gcc，使用clang你可以添加-target+mips或其他任何东西，所以你也可以看到ARM霓虹灯的自动矢量化，并使用正确的编译器选项来启用它。您可以将-m32与x86-64编译器一起使用，以获得32位代码生成。|2443541|int+sumint(int+*arr)+{
++++int+sum+=+0;
++++for+(int+i=0+;+i<2048+;+i%2B%2B){
++++++++sum+%2B=+arr[i];
++++}
++++return+sum;
}|code-block|syntax|javascript|2443542|带有gcc8.1+-O3的内循环(没有-march=haswell或任何支持AVX/avx2的东西)：|2443543|.L2:+++++++++++++++++++++++++++++++++#+do+{
++++movdqu++xmm2,+XMMWORD+PTR+[rdi]++++#+load+16+bytes
++++add+++++rdi,+16
++++paddd+++xmm0,+xmm2+++++++++++++++++#+packed+add+of+4+x+32-bit+integers
++++cmp+++++rax,+rdi
++++jne+++++.L2++++++++++++++++++++++#+}+while(p+!=+endp)

++++#+then+horizontal+add+and+extract+a+single+32-bit+sum|2443544|如果没有-ffast-math，编译器就不能重新排序FP操作，因此float等效项不会自动向量化(参见Godbolt链接:你会得到标量addss)。(OpenMP可以在每个循环的基础上启用它，或者使用-ffast-math)。|2443545|但是一些FP工具可以安全地自动向量化，而不会改变操作顺序。|2443546|//+clang+won't+contract+this+into+an+FMA+without+-ffast-math+:/
//+but+gcc+will+(if+you+compile+with+-march=haswell)
void+scale_array(float+*arr)+{
++++for+(int+i=0+;+i<2048+;+i%2B%2B){
++++++++arr[i]+=+arr[i]+*+2.1f+%2B+1.234f;
++++}
}

++#+load+constants:+xmm2+=+{2.1,++2.1,++2.1,++2.1}
++#+++++++++++++++++xmm1+=+(1.23,+1.23,+1.23,+1.23}
.L9:+++#+gcc8.1+-O3+++++++++++++++++++++++#+do+{
++++movups++xmm0,+XMMWORD+PTR+[rdi]+++++++++#+load+unaligned+packed+floats
++++add+++++rdi,+16
++++mulps+++xmm0,+xmm2++++++++++++++++++++++#+multiply+Packed+Single-precision
++++addps+++xmm0,+xmm1++++++++++++++++++++++#+add+Packed+Single-precision
++++movups++XMMWORD+PTR+[rdi-16],+xmm0++++++#+store+back+to+the+array
++++cmp+++++rax,+rdi
++++jne+++++.L9+++++++++++++++++++++++++++#+}while(p+!=+endp)|2443547|multiplier+=+2.0f导致使用addps加倍，将Haswell+/+Broadwell上的吞吐量减少2倍！因为在SKL之前，FP+add只在一个执行端口上运行，但有两个FMA单元可以运行乘法。SKL丢弃了加法器，并以与mul和FMA相同的每时钟2个吞吐量和延迟运行add。(http://agner.org/optimize/，并查看the+x86+tag+wiki中的其他性能链接。)|2443548|使用-march=haswell编译允许编译器使用单个FMA进行缩放%2B加法。(但是，除非使用-ffast-math，否则clang不会将表达式压缩为FMA。IIRC有一个选项可以在不进行其他激进操作的情况下启用FP收缩。)|2443549|entityMap|0|LINK|mutability|MUTABLE|url|http://agner.org/optimize/|1|https://stackoverflow.com/tags/x86/info^0|0|0|0|9|O|0|0|P|Q|9|0|P|39|5|3V|C|0|E|6|2J|5|0|O|W|O|U|2C|I|38|H|0|G|D|0|0|0|M|0|E|3K|1F|C|34|4|0|0|0|1F|2|A|J|E|0|0|0|35|4|B|X|5|1V|5|2S|B|0|0|T|0|0|0|5J|D|4|L|5|3Z|Q|0|4T|G|1|0|0|33|2|E|1A|B|0^^$0|@$1|2|3|4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1S|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|1U|8|@$G|1V|H|1W|I|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|1X|8|@$G|1Y|H|1Z|I|J]|$G|20|H|21|I|J]|$G|22|H|23|I|M]|$G|24|H|25|I|M]|$G|26|H|27|I|M]]|9|@]|A|$]]|$1|N|3|O|5|6|7|28|8|@$G|29|H|2A|I|M]|$G|2B|H|2C|I|M]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2D|8|@$G|2E|H|2F|I|J]|$G|2G|H|2H|I|M]|$G|2I|H|2J|I|M]|$G|2K|H|2L|I|M]]|9|@]|A|$]]|$1|R|3|S|5|6|7|2M|8|@$G|2N|H|2O|I|M]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2Q|8|@$G|2R|H|2S|I|J]]|9|@]|A|$]]|$1|W|3|X|5|6|7|2T|8|@$G|2U|H|2V|I|J]|$G|2W|H|2X|I|M]|$G|2Y|H|2Z|I|M]]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|30|8|@]|9|@]|A|$11|12]]|$1|13|3|14|5|6|7|31|8|@$G|32|H|33|I|J]|$G|34|H|35|I|M]|$G|36|H|37|I|M]]|9|@]|A|$]]|$1|15|3|16|5|10|7|38|8|@]|9|@]|A|$11|12]]|$1|17|3|18|5|6|7|39|8|@$G|3A|H|3B|I|J]|$G|3C|H|3D|I|M]|$G|3E|H|3F|I|M]|$G|3G|H|3H|I|M]|$G|3I|H|3J|I|M]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|3K|8|@$G|3L|H|3M|I|J]]|9|@]|A|$]]|$1|1B|3|1C|5|10|7|3N|8|@]|9|@]|A|$11|12]]|$1|1D|3|1E|5|6|7|3O|8|@$G|3P|H|3Q|I|J]|$G|3R|H|3S|I|M]|$G|3T|H|3U|I|M]]|9|@$G|3V|H|3W|1|3X]|$G|3Y|H|3Z|1|40]]|A|$]]|$1|1F|3|1G|5|6|7|41|8|@$G|42|H|43|I|J]|$G|44|H|45|I|M]|$G|46|H|47|I|M]]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|48|8|@]|9|@]|A|$]]]|1I|$1J|$5|1K|1L|1M|A|$1N|1O]]|1P|$5|1K|1L|1M|A|$1N|1Q]]]]

Yes, modern compilers auto-vectorize with SSE2 if you compile with full optimization. clang enables it even at -O2, gcc at -O3.

Even at -O1 or -Os, compilers will use SIMD load/store instructions to copy or initialize structs or other objects wider than an integer register. That doesn't really count as auto-vectorization; it's more like part of their default builtin memset / memcpy strategy for small fixed-size blocks. But it does take advantage of and require SIMD instructions to be supported.

<hr>

SSE2 is baseline / non-optional for x86-64, so compilers can always use SSE1/SSE2 instructions when targeting x86-64. Later instruction sets (SSE4, AVX, AVX2, AVX512, and non-SIMD extensions like BMI2, popcnt, etc.) have to be enabled manually to tell the compiler it's ok to make code that won't run on older CPUs. Or to get it to generate multiple versions of code and choose at runtime, but that has extra overhead and is only worth it for larger functions.

<code>-msse -msse2 -mfpmath=sse</code> is already the default for x86-64, but not for 32-bit i386. Some 32-bit calling conventions return FP values in x87 registers, so it can be inconvenient to use SSE/SSE2 for computation and then have to store/reload the result to get it in x87 <code>st(0)</code>. With <code>-mfpmath=sse</code>, smarter compilers might still use x87 for a calculation that produces an FP return value.

On 32-bit x86, <code>-msse2</code> might not be on by default, it depends on how your compiler was configured. If you're using 32-bit because you're targeting CPUs that are so old they can't run 64-bit code, you might want to make sure it's disabled, or only <code>-msse</code>.

The best way to make a binary tuned for the CPU you're compiling on is <code>-O3 -march=native -mfpmath=sse</code>, and use link-time optimization + profile-guided optimization. (gcc <code>-fprofile-generate</code> / run on some test data / <code>gcc -fprofile-use</code>).

Using <code>-march=native</code> makes binaries that might not run on earlier CPUs, if the compiler does choose to use new instructions. Profile-guided optimization is very helpful for gcc: it never unrolls loops without it. But with PGO, it knows which loops run often / for a lot of iterations, i.e. which loops are "hot" and worth spending more code-size on. Link-time optimization allows inlining / constant-propagation across files. It's very helpful if you have C++ with a lot of small functions that you don't actually define in header files.

<hr>

See <a href="https://stackoverflow.com/questions/38552116/how-to-remove-noise-from-gcc-clang-assembly-output">How to remove &quot;noise&quot; from GCC/clang assembly output?</a> for more about looking at compiler output and making sense of it.

Here are some specific examples <a href="https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:c%2B%2B,source:&#39;int+sumint(int+*arr)+%7B%0A++++int+sum+%3D+0%3B%0A++++for+(int+i%3D0+%3B+i%3C2048+%3B+i%2B%2B)%7B%0A++++++++sum+%2B%3D+arr%5Bi%5D%3B%0A++++%7D%0A++++return+sum%3B%0A%7D%0A%0A//+FP+reductions+only+auto-vectorize+with+-ffast-math%0Afloat+sumfloat(float+*arr)+%7B%0A++++float+sum+%3D+0%3B%0A++++for+(int+i%3D0+%3B+i%3C2048+%3B+i%2B%2B)%7B%0A++++++++sum+%2B%3D+arr%5Bi%5D%3B%0A++++%7D%0A++++return+sum%3B%0A%7D%0A%0A//+clang+won!&#39;t+contract+this+into+an+FMA+without+-ffast-math+:/%0A//+but+gcc+will+(if+you+compile+with+-march%3Dhaswell)%0Avoid+scale_array(float+*arr)+%7B%0A++++for+(int+i%3D0+%3B+i%3C2048+%3B+i%2B%2B)%7B%0A++++++++arr%5Bi%5D+%3D+arr%5Bi%5D+*+2.1f+%2B+1.234f%3B%0A++++%7D%0A%7D%0A//+multiplier+%3D+2.0+results+in+using+addps+to+double%0A//+cutting+throughput+by+a+factor+of+2+on+Intel+pre-Skylake!!&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;C%2B%2B+source+%231&#39;,t:&#39;0&#39;)),k:35.77299704436006,l:&#39;4&#39;,m:100,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:g81,filters:(b:&#39;0&#39;,binary:&#39;1&#39;,commentOnly:&#39;0&#39;,demangle:&#39;0&#39;,directives:&#39;0&#39;,execute:&#39;1&#39;,intel:&#39;0&#39;,trim:&#39;1&#39;),lang:c%2B%2B,libs:!(),options:&#39;-xc+-Wall+-O3&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+gcc+8.1+(Editor+%231,+Compiler+%231)+C%2B%2B&#39;,t:&#39;0&#39;)),k:33.38351320157121,l:&#39;4&#39;,m:100,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:clang600,filters:(b:&#39;0&#39;,binary:&#39;1&#39;,commentOnly:&#39;0&#39;,demangle:&#39;0&#39;,directives:&#39;0&#39;,execute:&#39;1&#39;,intel:&#39;0&#39;,trim:&#39;1&#39;),lang:c%2B%2B,libs:!(),options:&#39;-xc+-Wall+-O3+-march%3Dskylake&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+clang+6.0.0+(Editor+%231,+Compiler+%233)+C%2B%2B&#39;,t:&#39;0&#39;)),k:30.48018830193644,l:&#39;4&#39;,m:100,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;)),l:&#39;2&#39;,n:&#39;0&#39;,o:&#39;&#39;,t:&#39;0&#39;)),version:4" rel="noreferrer">on the Godbolt compiler explorer</a> for x86-64. Godbolt also has gcc for several other architectures, and with clang you can add <code>-target mips</code> or whatever, so you can also see auto-vectorization for ARM NEON with the right compiler options to enable it. You can use <code>-m32</code> with the x86-64 compilers to get 32-bit code-gen.

<pre><code>int sumint(int *arr) {
 int sum = 0;
 for (int i=0 ; i&lt;2048 ; i++){
 sum += arr[i];
 }
 return sum;
}
</code></pre>

inner loop with <code>gcc8.1 -O3</code> (without <code>-march=haswell</code> or anything to enable AVX/AVX2):

<pre><code>.L2: # do {
 movdqu xmm2, XMMWORD PTR [rdi] # load 16 bytes
 add rdi, 16
 paddd xmm0, xmm2 # packed add of 4 x 32-bit integers
 cmp rax, rdi
 jne .L2 # } while(p != endp)

 # then horizontal add and extract a single 32-bit sum
</code></pre>

Without <code>-ffast-math</code>, compilers can't reorder FP operations, so the <code>float</code> equivalent don't auto-vectorize (see the Godbolt link: you get scalar <code>addss</code>). (OpenMP can enable it on a per-loop basis, or use <code>-ffast-math</code>).

But some FP stuff can safely auto-vectorize without changing order of operations.

<pre><code>// clang won't contract this into an FMA without -ffast-math :/
// but gcc will (if you compile with -march=haswell)
void scale_array(float *arr) {
 for (int i=0 ; i&lt;2048 ; i++){
 arr[i] = arr[i] * 2.1f + 1.234f;
 }
}

 # load constants: xmm2 = {2.1, 2.1, 2.1, 2.1}
 # xmm1 = (1.23, 1.23, 1.23, 1.23}
.L9: # gcc8.1 -O3 # do {
 movups xmm0, XMMWORD PTR [rdi] # load unaligned packed floats
 add rdi, 16
 mulps xmm0, xmm2 # multiply Packed Single-precision
 addps xmm0, xmm1 # add Packed Single-precision
 movups XMMWORD PTR [rdi-16], xmm0 # store back to the array
 cmp rax, rdi
 jne .L9 # }while(p != endp)
</code></pre>

multiplier = <code>2.0f</code> results in using <code>addps</code> to double, cutting throughput by a factor of 2 on Haswell / Broadwell! Because before SKL, FP add only runs on one execution port, but there are two FMA units that can run multiplies. SKL dropped the adder and runs add with the same 2 per clock throughput and latency as mul and FMA. (<a href="http://agner.org/optimize/" rel="noreferrer">http://agner.org/optimize/</a>, and see other performance links in <a href="https://stackoverflow.com/tags/x86/info">the x86 tag wiki</a>.)

Compiling with <code>-march=haswell</code> lets the compiler use a single FMA for the scale + add. (But clang won't contract the expression into an FMA unless you use <code>-ffast-math</code>. IIRC there's an option to enable FP contraction without other aggressive operations.)

I see people using <code>-msse -msse2 -mfpmath=sse</code> flags by default hoping that this will improve performance. I know that SSE gets engaged when special vector types are used in the C code. But do these flags make any difference for regular C code? Does compiler use SSE to optimize regular C code?

Does compiler use SSE instructions for a regular C code?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我看到人们默认使用-msse -msse2 -mfpmath=sse标志，希望这能提高性能。我知道当在C代码中使用特殊的向量类型时，SSE就会被使用。但是这些标志对普通的C代码有什么不同吗？编译器是否使用SSE来优化常规C代码？

编译器是否对常规C代码使用SSE指令？-腾讯云开发者社区-腾讯云

问编译器是否对常规C代码使用SSE指令？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编译器是否对常规C代码使用SSE指令？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问编译器是否对常规C代码使用SSE指令？
EN