L1/L2 cache characteristics and -mtune=znver2 versus run-time detection

L1/L2 cache characteristics and -mtune=znver2 versus run-time detection

[Sven C. Dack]

Hello,

I've come across an unexpected behaviour of gcc and wanted to ask for
help. I've noticed that when I specify '-march=znver2' does gcc use the
incorrect values for the L1/L2 cache. Only when '-march=native' was used
and gcc detected the CPU at run-time does it use the correct values. For
example on a Ryzen 7 3800X (a Zen 2 CPU):

$ gcc -march=znver2 --help=params -Q|fgrep cache
   --param=l1-cache-line-size=         32
   --param=l1-cache-size=              64
   --param=l2-cache-size=              512

versus:

$ gcc -march=native --help=params -Q|fgrep cache
   --param=l1-cache-line-size=         64
   --param=l1-cache-size=              32
   --param=l2-cache-size=              512

GCC does detect the CPU as 'znver2':

$ gcc -march=native --help=target -Q|fgrep march
   -march=                             znver2

I've also verified this behaviour with '-mtune=znver2', and again does
GCC only use the correct values when it uses auto-detection.

Why does GCC not use the correct L1/L2 cache values when '-march=znver2'
or '-mtune=znver2' is specified?

Sven

Re: L1/L2 cache characteristics and -mtune=znver2 versus run-time detection

[Sven C. Dack]

Could some of the GCC experts please share their knowledge on this issue?


On 05/12/2020 17:46, Sven C. Dack wrote:
> Hello,
>
> I've come across an unexpected behaviour of gcc and wanted to ask for
> help. I've noticed that when I specify '-march=znver2' does gcc use the
> incorrect values for the L1/L2 cache. Only when '-march=native' was used
> and gcc detected the CPU at run-time does it use the correct values. For
> example on a Ryzen 7 3800X (a Zen 2 CPU):
>
> $ gcc -march=znver2 --help=params -Q|fgrep cache
>   --param=l1-cache-line-size=         32
>   --param=l1-cache-size=              64
>   --param=l2-cache-size=              512
>
> versus:
>
> $ gcc -march=native --help=params -Q|fgrep cache
>   --param=l1-cache-line-size=         64
>   --param=l1-cache-size=              32
>   --param=l2-cache-size=              512
>
> GCC does detect the CPU as 'znver2':
>
> $ gcc -march=native --help=target -Q|fgrep march
>   -march=                             znver2
>
> I've also verified this behaviour with '-mtune=znver2', and again does
> GCC only use the correct values when it uses auto-detection.
>
> Why does GCC not use the correct L1/L2 cache values when '-march=znver2'
> or '-mtune=znver2' is specified?
>
> Sven
>

Re: L1/L2 cache characteristics and -mtune=znver2 versus run-time detection

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 04:30:00PM +0000, Sven C. Dack via Gcc-help wrote:
> Could some of the GCC experts please share their knowledge on this issue?

> >I've come across an unexpected behaviour of gcc and wanted to ask for
> >help. I've noticed that when I specify '-march=znver2' does gcc use the
> >incorrect values for the L1/L2 cache. Only when '-march=native' was used
> >and gcc detected the CPU at run-time does it use the correct values. For
> >example on a Ryzen 7 3800X (a Zen 2 CPU):

-march=native uses cpuid to get the cache info (or in general, looks at
the system it is running on).  -march=znver2 does not.  I do not know if
-march=znver2 should use better defaults.

> >Why does GCC not use the correct L1/L2 cache values when '-march=znver2'
> >or '-mtune=znver2' is specified?

Please open a PR?  https://gcc.gnu.org/bugs.html .  Thanks!


Segher

Re: L1/L2 cache characteristics and -mtune=znver2 versus run-time detection

[Sven C. Dack]

Hello,

I've seen the PR got resolved now and I still need to compile it. It
appears it got fixed 4 days after my first email to gcc-help regarding
this issue. It only never received a reply. Anyhow, I'm glad it got
fixed now.

Merry Christmas!


On 18/12/2020 10:19, Segher Boessenkool wrote:
> On Fri, Dec 18, 2020 at 04:15:12AM -0600, Segher Boessenkool wrote:
>> On Thu, Dec 17, 2020 at 10:24:17PM +0000, Sven C. Dack wrote:
>>> Thank you. I've created a PR. You can find it here:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98361
>>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98361>
>> Thanks you!  You might went to not exclude the mailing list though?  :-)
> Oh, I see Martin says it is already fixed (by Ke Wen).  Could you check
> if you see the same?
>
>
> Segher