On Mon, Aug 21, 2023 at 5:35 PM Richard Biener <richard.guent...@gmail.com> wrote: > > 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?! We're only allowing a single vector width. -mavx10.1-512 mavx10.2-256 will only enable -mavx10.2-256 + -mavx10.1-256. > I think we opened up too many holes here and the options should be fixed > to decouple the size from the base ISA. I see, we can try to use -mavx-max-512bit(maybe another name) to decouple the size from the base ISA. And make -mavx10.1-256 just implies all -mavx512XXX + -mno-avx-max-512bit, -mavx10.1-512 implies -mavx512XXX + mavx-max-512bit. then -mavx512vl-256 is just equal to -mavx512vl + mno-avx-max-512bit.
Lots of work to do, but still not too late for GCC14.1 > > 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 -- BR, Hongtao
