| 1 |
On 01/05/15 10:44, Andrew Savchenko wrote: |
| 2 |
> On Fri, 1 May 2015 05:09:51 +0000 (UTC) Martin Vaeth wrote: |
| 3 |
>> Andrew Savchenko <bircoph@g.o> wrote: |
| 4 |
>>> |
| 5 |
>>> That's why kernel makes sure that no floating point instructions |
| 6 |
>>> sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set} |
| 7 |
>>> flags when running make -V. |
| 8 |
>> |
| 9 |
>> So it should be sufficient that the kernel does not use "float" |
| 10 |
>> or "double", shouldn't it? |
| 11 |
> |
| 12 |
> No. Optimizer paths may be very unobvious, i.e. I'll not be |
| 13 |
> surprised if under some conditions vectorizer may use float |
| 14 |
> instructions for int code. |
| 15 |
|
| 16 |
The kernel uses -O2 and several -march variants (e.g. -march=core2). |
| 17 |
Several other options are used to prevent GCC from generating unsuitable |
| 18 |
code. |
| 19 |
|
| 20 |
Specifying another -march variant does not affect the optimizer though. |
| 21 |
It only affects the code generator. If you don't modify the other CFLAGS |
| 22 |
and only change -march, you will not get FP instructions unless you use |
| 23 |
FP in the code. |
| 24 |
|
| 25 |
Also, I'd be very interested to see *any* optimization that would |
| 26 |
somehow transform integer code to FP code (note that SIMD is not FP and |
| 27 |
is perfectly fine in the kernel.) In fact, optimizers tend to transform |
| 28 |
FP into SIMD, at least on x86 (and other architectures that have fast |
| 29 |
SIMD instructions.) If I inspect the generated assembly from GCC or |
| 30 |
Clang, I cannot find FP anywhere, even for code using "float" and |
| 31 |
"double" operations. They get converted to SIMD on modern CPUs (unless |
| 32 |
you specify a compiler flag that tells it to use the FPU, for example if |
| 33 |
you need 80-bit extended precision, which is supported by the x86 FPU.) |
Archives