On Mon, Aug 21, 2023 at 10:28 AM Hongtao Liu <crazy...@gmail.com> wrote: > > 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.
Ah, missed that, but ... > 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. ... -mno-avx10-max-512bit sounds awkward, no-..-max implies the max doesn't apply, so what is it then? If you think -mavx512vl-256 isn't good then maybe -mavx-width-512 and -mno-avx-width-512 would be better (applying to both avx512 and avx10). I chose -mavx512vl-256 because of the existing -mavx10.1-256. Btw, will we then have -mavx10.2-256 as well? Do we allow -mavx10.1-512 -mavx10.2-256 then, thus just enable 256bit for 10.2 extensions to 10.1?! I think we opened up too many holes here and the options should be fixed to decouple the size from the base ISA. What variable we map this to internally doesn't really matter but yes, we'd need to guard 512bit patterns with (AVX512VL || AVX10) && 512-enabled-flag Richard. > 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
