GCC: Discrepancy between --param "l2-cache-size=..." and CPU hardware

English Programming/Scripting
1

Hi,

Gentoo’s GCC optimization article says that command


gcc -### -march=native /usr/include/stdlib.h

“will show the compiler directives for building the header file, but without actually performing the steps and instead showing them on the screen (-###)”.

Looking its output I noticed something strange (the architecture is detected correctly as ivybridge):


... --param "l1-cache-size=32" --param "l1-cache-line-size=64" **--param "l2-cache-size=8192"** ...

but the actual L2 cache size available in the physical CPU is smaller:


~]: lscpu | grep -i cache
L1d cache:           32K
L1i cache:           32K
**L2 cache:            256K**
L3 cache:            8192K

According to man gcc the ‘–param name=value’ are constants, i.e not something detected from the hardware.

So I wonder:

  1. Should I set explicitly ‘–param “l2-cache-size=256”’?

OR

  1. What negative effect could one expect if one allows gcc to set a cache which is not physically available?
2
  1. Might that be a bug in gcc?

(according to man page “-mtune=native causes the compiler to auto-detect the CPU of the build computer.” and its cache is obviously not detecte correctly)

3

On Tue 25 Sep 2018 09:36:02 PM CDT, heyjoe wrote:

Hi,

‘Gentoo’s GCC optimization’
(GCC optimization - Gentoo wiki) article says that
command

Code:

gcc -### -march=native /usr/include/stdlib.h

“will show the compiler directives for building the header file, but
without actually performing the steps and instead showing them on the
screen (-###)”.

Looking its output I noticed something strange (the architecture is
detected correctly as ivybridge):

Code:

… --param “l1-cache-size=32” --param “l1-cache-line-size=64”
–param “l2-cache-size=8192” …

but the actual L2 cache size available in the physical CPU is smaller:

Code:

~]: lscpu | grep -i cache
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K

According to man gcc the ‘–param name=value’ are constants, i.e not
something detected from the hardware.

So I wonder:

  1. Should I set explicitly ‘–param “l2-cache-size=256”’?

OR

  1. What negative effect could one expect if one allows gcc to set a
    cache which is not physically available?

Hi
I would surmise a bug, picking the L3 cache for that particular cpu
(or cpu’s with L3 cache?)…

I see it here with openSUSE Leap 15.0;


lscpu |egrep "Model name|cache"
Model name:          Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            3072K

gcc -### -march=native /usr/include/stdlib.h
......
gcc version 7.3.1 20180323 [gcc-7-branch revision 258812] (SUSE Linux)
......
--param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=3072"

I don’t see the error with AMD cpu’s (or cpu’s with no L3 cache)


lscpu |egrep "Model name|cache"

Model name:            Intel(R) Core(TM)2 Duo CPU     T6500  @ 2.10GHz
L1d cache:             32K
L1i cache:             32K
L2 cache:              2048K

gcc -### -march=native /usr/include/stdlib.h
.....
gcc version 4.8.5 (SUSE Linux)
.....
--param "l1-cache-size=32" --param "l1-cache-line-size=64" --param
"l2-cache-size=2048"

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.16-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

4

Thanks Malcolm.
I filed a bug report.

Do you know the answer to question 2?

5

And how comes it is suddenly openSUSE bug? Did you even try to ask GCC about this behavior?

6

Are you suggesting that only bugs for software created by SUSE should be reported? (i.e. - no kernel bug reports and no reports for any common FOSS software)

Did you even try to ask GCC about this behavior?

Their bugzilla is not sending me a confirmation email, so I can’t register. Waiting for feedback.

7

So it seems it is not a bug but something else:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444