Which of gcc's -O3 optimization flags enable "hardware accelerated instructions" - c

Question

So basically, for my project, there is a restriction that it must not use the -O3 flag (we must only use -O2). The reasoning for this is that the -O3 flag apparently introduces "hardware accelerated instructions".
The gcc version is 5.4 and the manual page for this version's optimization flags is: this
I want to include as many of -O3's flags as possible.
The list of flags introduced by -O3 are:
-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-loop-distribute-patterns, -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone
So I am planning to use -O2 and manually include as many of the above flags as possible.
Which flags above enable "hardware accelerated instructions" optimizations? How can I tell if a flag enables "hardware accelerated instructions" optimizations by reading the descriptions? What constitutes that?

Answer 1

The set of instructions used is controlled by -march, not by -O3. It is true that -O3 may make more use of SIMD instructions for vectorization, but -O3 does not specifically add or remove instructions from consideration during code generation.
If you want to compile your code with the simplest instructions only, choose the simplest march for your platform. For example, -march=core2 would be a conservative choice for x86-64, as this refers to the Intel Core 2 processor family which is quite old.
Still, Core 2 supports MMX and SSE to SSE3 and SSSE3. To disable those, add:
-mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3

Answer 2

I feel like John has already answered this question, I will try to provide some examples.
Consider following minimal program:
#include <cstring>
void copy(long *dst , const long *src)
{
std::memcpy(dst, src, sizeof(long) * 4);
}
Compiled with GCC 7.2 g++ -O2 at x86_64 gives following output:
copy(long*, long const*):
movdqu (%rsi), %xmm0
movups %xmm0, (%rdi)
movdqu 16(%rsi), %xmm0
movups %xmm0, 16(%rdi)
ret
Compiled with GCC 7.2 g++ -O2 -mno-sse at x86_64 gives following output:
copy(long*, long const*):
movq (%rsi), %rax
movq %rax, (%rdi)
movq 8(%rsi), %rax
movq %rax, 8(%rdi)
movq 16(%rsi), %rax
movq %rax, 16(%rdi)
movq 24(%rsi), %rax
movq %rax, 24(%rdi)
ret
As you can see, GCC is able to generate SSE instructions even at -O2 level. Separate flag is required to suppress generation of those instructions.
At the same time GCC 5.4 generates the same code with and without -mno-sse flag, but it also does the same for -O3 optimization level.
So your goal is a bit misleading here. Using superset of -O2 flags might suppress generation of SSE and similar instructions in some cases, but this is not guaranteed as optimization level is only indirectly related to what instructions are generated. If you really want to suppress those, you can use -mno-sse flag, but this will probably put you at disadvantage. Just stick with -O2 - this way everyone will be on equal terms.
I used https://godbolt.org/ to demonstrate this.

Answer 3

I would like to add a couple.
Your TA said:
Using -O3 enables hardward accelerated instructions such as SSE
I think that's not really correct. It seems like -f options are intended to be machine-independent. A compiler parses the source code and transforms it into, generally, something called intermediate representations (IRs). Following that, a compiler optimizes IR itself so-called machine-independently. Then, the assembly code is generated from the optimized IR. When the assembly is generated, a different set of optimizations are applied. Examples of IR would be LLVM IR, Sun IR, GCC gimple tree and/or RTL, etc. I believe all modern compiler have IR(s).
GCC's -f options are, I believe, basically intended to be machine-independent. -m options are for machine-dependent optimizations. -O2 or -O3 determines -f options, which are ideally machine-independent. Using fancy instructions is up to machine-dependent parts of a compiler.
In reality, the boarder line between machine-dependent and machine-independent worlds might not be crystal clear.
Vectorization turned on by -O3 would be an example of optimizations in a gray area. Some machines do not support SIMD. Some do but the vector size, for example, is different from architecture to architecture. Here is my example code:
// code.c
long long int inner_product(int* v0, int* v1, int sz) {
long long int res = 0;
for (int i = 0; i < sz; i++) {
res += (v0[i] * v1[i]);
}
return res;
}
If it is compiled as follows:
$ gcc -O3 -S -march=core2 code.c -o code.s -fdump-tree-all
Gcc vectorizes it but the vector size is 2 long long ints or 4 ints:
$ cat code.*.optimized | grep 'vector('
vector(2) long long int vect_res_16.21;
vector(2) long long int vect_res_16.19;
vector(2) long long int vect__8.18;
vector(4) int vect__7.17;
vector(4) int vect__6.16;
vector(4) int * vectp_v1.15;
vector(4) int vect__4.13;
vector(4) int * vectp_v0.12;
On the other hands, if it is compiled with -march=skylake-avx512, whose vector size is 4 times bigger than core2, the outcome would be:
$ gcc -O3 -S -march=skylake-avx512 code.c -o code.s -fdump-tree-all && cat code.*.optimized | grep 'vector('
vector(8) long long int vect_res_16.21;
vector(8) long long int vect_res_16.19;
vector(8) long long int vect__8.18;
vector(16) int vect__7.17;
vector(16) int vect__6.16;
vector(16) int * vectp_v1.15;
vector(16) int vect__4.13;
vector(16) int * vectp_v0.12;
Note that the code generation did not yet start at this point. The IR looks different depending on the march value. I guess vectorization is not the only example that shows this kind of behavior.
Nonetheless, I do not think that it is fair to call such optimizations machine-dependent. A typical machine dependent optimization is instruction scheduling. It has almost nothing to do with intermediate representations. It is more about machine instructions and the micro-architecture. For those machine-independent optimizations in a gray area, conceptually, a compiler can generate unified vectorized IR (say, making vector size always 4), and let the code generator deals with it (each code generator may need to merge or split vector operands). However, in implementation, giving an appropriate size to a vector operand is regarded as easier at the IR level than at the code generation level. So, I guess people gave up living in the world of "Ideas." Nonetheless, I believe that machine-independent optimizations could be referred as machine-independent yet.
You might need to ask what kind of fancy instructions the TA does not want to see. If that's only vector instructions, all vector-related flags should be disabled but you could use -O3. My example code could be used to see if there is still SIMD instructions:
$ gcc -O3 -S code.c
$ cat code.s | egrep xmm
If the output is empty, you are good.