On Thu, Mar 20, 2025 at 2:37 AM Liu, Hongtao <hongtao....@intel.com> wrote: > > > > > -----Original Message----- > > From: Jiang, Haochen <haochen.ji...@intel.com> > > Sent: Wednesday, March 19, 2025 3:38 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Liu, Hongtao <hongtao....@intel.com>; ubiz...@gmail.com > > Subject: [PATCH 00/27] Use avx10.x as the only option for AVX10 with 512 bit > > vector support while remove avx10.x-256/512 option and 256 bit rounding > > support > > > > Hi all, > > > > It is a little late for this change but I hope this will be a welcoming > > change since > > it will greatly simplify the compiler options and reduce confusion for AVX10 > > option combination with AVX512. > > > > AVX10 whitepaper just got a major change and it will impact how we design > > the compiler option, which will actually simplify everything. > I like the decision.
I also like the decision. Hopefully they stick to it this time ... Richard. > Ok for the series. > But I'd like to leave a little time for others to comment. so please COMMIT > this series in next week if there's no objection. > > > > Ref: https://cdrdv2.intel.com/v1/dl/getContent/784343 > > > > In this new whitepaper, all the platforms will support 512 bit vector width > > (previously, E-core is up to 256 bit, leading to hybrid clients and Atom > > Server > > 256 bit only). Also, 256 bit rounding is not that useful because we > > currently > > have rounding feature directly on E-core now and no need to use 256-bit > > rounding as somehow a workaround. HW will remove that support. > > > > Thus, there is no need to add avx10.x-256/512 into compiler options. A > > simple avx10.x supporting all vector length is all we need. The change also > > makes -mno-evex512 not that useful. It is introduced with avx10.1-256 for > > compiling 256 bit only binary on legacy platforms to have a partial trial > > for > > avx10.x-256. What we also need to do is to remove 256 bit rounding. > > > > For new features added in GCC 15 (i.e., option avx10.2-256/512 and 256 bit > > rounding), we will just simply remove them. Since avx10.2 has been directed > > to 512 bit previously. No need to change that option. We will keep the > > testcase > > and intrin file structure for now since it is late in GCC 15 release cycle > > and do > > clean up in GCC 16. > > > > For features added in GCC 14 (i.e., option avx10.1-256/512 and no-evex512), > > we will raise a deprecate warning in GCC 15 and finally remove them in GCC > > 16. Also, we will need to add avx10.1 back (it was removed just less than > > one > > month ago) and direct it to 512 bit with a warning in GCC 15 since it was > > aliased to 256 bit previously. The deprecate and re-alias warning would also > > like to be backported to GCC 14 and landed into GCC 14.3. > > > > The change will also lead to AVX10 and AVX512 option combination design > > simplification. Since we do not need to consider vector width enabled > > anymore, it is much more natural to just treat avx10.1 to an alias of all > > avx512xxx in SPR. Thus, "-mavx10.1 -mno-avx512fp16" should enable all > > AVX512 features while disabling AVX512FP16. And "-mavx512f -mno- > > avx10.1" > > should disable all AVX512 features. Both of the two combinations currently > > will ignore "-mno-". In GCC 15, we will raise a warning to mention that we > > are > > going to change that behavior in GCC 16. > > > > Upcoming would be the patches we want to landed in GCC 15. The first two > > patches are removing 256 bit roundings added with AVX10.2 new > > instructions. > > Then the following 22 are simple revert patch for the legacy instruction > > 256 bit ymm rounding addition. The last three patch is for avx10.x option > > change. > > > > Thx, > > Haochen > > >
