On Mon, Aug 21, 2023 at 4:09 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Aug 21, 2023 at 09:36:16AM +0200, Richard Biener via Gcc-patches > wrote: > > > On Sun, Aug 20, 2023 at 6:44 AM ZiNgA BuRgA via Gcc-patches > > > <gcc-patches@gcc.gnu.org> wrote: > > > > > > > > Hi, > > > > > > > > With the proposed design of these switches, how would I restrict AVX10.1 > > > > to particular AVX-512 subsets? > > > We can't, avx10.1 is taken as an indivisible ISA which contains all > > > AVX512 related instructions. > > > > > > > We’ve been taking these cases as bugs (but yes, intrinsics are still > > > > allowed, so in some cases it might prove difficult to guarantee this). > > > intel sde support avx10.1-256 target which can be used to validate the > > > binary(if there's invalid 512-bit vector register or 64-bit kmask > > > register is used). > > > > I don’t see any other way of doing what you want within the constraints > > > > of this design. > > > It looks like the requirement is that we want a > > > -mavx10-vector-width=256(or maybe reuse -mprefer-vector-width=256) > > > option that acts on the original -mavx512XXX option to produce > > > avx10.1-256 compatible binary. we can't use -mavx10.1-256 since it may > > > include avx512fp16 directives and thus not be backward compatible > > > SKX/CLX/ICX. > > > > Yes. Note we cannot really re-purpose -mprefer-vector-width=256 since that > > would also make uses of 512bit intrinsics ill-formed. So we'd need a new > > flag that would restrict AVX512VL to 256bit, possibly using a common > > internal > > flag for this and the -mavx10.1-256 vector size effect. > > > > Maybe -mdisable-vector-width-512 or -mavx512vl-for-avx10.1-256 or > > -mavx512vl-256? Writing these the last looks most sensible to me? > > Note it should combine with -mavx512vl to -mavx512vl-256 to make > > -march=native -mavx512vl-256 work (I think we should also allow the > > flag together with -mavx10.1*?) > > > > mavx512vl-256 > > Target ... > > Disable the 512bit vector ISA subset of AVX512 or AVX10, enable > > the 256bit vector ISA subset of AVX512. > > Wouldn't it be better to have it similarly to other ISA options as something > positive, say -mevex512 (the ISA docs talk about EVEX.512, EVEX.256 and > EVEX.128)? > Have -mavx512f (and anything that implies it right now) imply also -mevex512 > but allow -mno-evex512 which wouldn't unset everything dependent on > -mavx512f. There is one gotcha, if -mavx512vl isn't enabled in the end, > then -mavx512f -mno-evex512 should disable whole TARGET_AVX512F because > nothing is left. > TARGET_EVEX512 then would guard all TARGET_AVX512* intrinsics which operate > on 512-bit vector registers or 64-bit mask registers (in addition to the > other TARGET_AVX512* options, perhaps except TARGET_AVX512F), whether the > 512-bit modes can be used etc. We have an undocumented option mavx10-max-512bit.
1314;; Only for implementation use 1315mavx10-max-512bit 1316Target Mask(ISA2_AVX10_512BIT) Var(ix86_isa_flags2) Undocumented Save 1317Indicates 512 bit vector width support for AVX10. Currently it's only used for AVX10 only, maybe we can extend it to existing AVX512*** FLAGS. so users can use -mavx512XXX -mno-avx10-max-512bit to get avx10.1-256 compatible binaries. >From the implementation perspective, we need to restrict all 512-bit vector patterns/builtins/intrinsics under both AVX512XXX and TARGET_AVX10_512BIT. similar for register allocation, parameter passing, return value, vector_mode_supported_p, gather/scatter hook, and all other hooks. After that, the -mavx10-max-512bit will divide existing AVX512 into 2 parts, AVX512XXX-256, AVX512XXX-512. > > Jakub > -- BR, Hongtao
