https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #13 from David C. Manuelda ---
I'd suggest for now to pick a common value in order to prevent the compilation
failure (in stage comparison) while a proper fix/workaround is picked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #11 from Alexander Monakov ---
(In reply to Hongtao.liu from comment #10)
> > indeed (but I believe it did happen with Alder Lake already, by accident,
> > with AVX512 on P-cores but not on E-cores).
>
> AVX512 is physically fused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #10 from Hongtao.liu ---
> indeed (but I believe it did happen with Alder Lake already, by accident,
> with AVX512 on P-cores but not on E-cores).
AVX512 is physically fused off for Alderlake P-core, P-core and E-core share
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #9 from Alexander Monakov ---
(In reply to Arsen Arsenović from comment #8)
> indeed (but I believe it did happen with Alder Lake already, by accident,
> with AVX512 on P-cores but not on E-cores).
AFAIK on those Alder Lake CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #8 from Arsen Arsenović ---
(In reply to Alexander Monakov from comment #7)
> I'm afraid hybrid CPUs with varying ISA feature sets are not practical for
> the current ecosystem: you wouldn't be able to reschedule from a higher- to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #6 from Arsen Arsenović ---
this poses another problem too, though: should big and little cores ever differ
in ISA support levels, building on big cores (which seems like a reasonable
thing to do) with -march=native could lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #5 from Alexander Monakov ---
I think it's similar to attempting -march=native under distcc, which is already
warned about on Gentoo wiki: https://wiki.gentoo.org/wiki/Distcc
The difference here is that Intel so far decided to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #4 from Hongtao.liu ---
I checked Alderlake's L1 cachesize and it is indeed 48, and L1 cachesize in
alderlake_cost is set to 32.
But then again, we have a lot of different platforms that share the same cost
and they may have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #3 from Richard Biener ---
I'd say "don't do this" (bootstrap with -march=native). Alternatively use a
taskset to confine to either big or little cores.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #2 from Andrew Pinski ---
I think on those soc we should ignore the cache info or set it to some common
value between the 2.
12 matches
Mail list logo
