On Fri, Sep 01, 2023 at 07:34:16PM +0800, Hongyu Wang wrote: > > On Fri, Sep 01, 2023 at 05:07:53PM +0800, Hongyu Wang wrote: > > > Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年8月31日周四 > > > 17:44写道: > > > > > > > > On Thu, Aug 31, 2023 at 04:20:19PM +0800, Hongyu Wang via Gcc-patches > > > > wrote: > > > > > For vector move insns like vmovdqa/vmovdqu, their evex counterparts > > > > > requrire explicit suffix 64/32/16/8. The usage of these instruction > > > > > are prohibited under AVX10_1 or AVX512F, so for AVX2+APX_F we select > > > > > vmovaps/vmovups for vector load/store insns that contains EGPR. > > > > > > > > Why not make it dependent on AVX512VL? > > > > I.e. if egpr_p && TARGET_AVX512VL, still use vmovdqu16 or vmovdqa16 > > > > and the like, and only if !evex_reg_p && egpr_p && !TARGET_AVX512VL > > > > fall back to what you're doing? > > > > > > I'm not sure if it is necessary, as on hardware there is no difference > > > between > > > vmovdqu16/vmovups. If vmovups already has the capability to represent > > > EGPR why do we need to distinguish them under VL? > > > > On the Intel HW you're currently planning. > > Will that be the case for AMD as well? > > Some insns are documented to move float or double vectors while others > > integer vectors (of different element sizes). > > Or is vmovups with GPR32 at least encoded smaller than vmovdqu{16,32,64}? > > With GPR32 they have same encoding size. If we need to strictly follow > the meaning of mnemonics, > I will adjust as you suggested. Thanks.
I think it is useful, even if just for those who try to read the assembler/disassembler. Of course, if there are cases where only one of those has to be used (say -mavx -mno-avx2 and 256-bit integer vector moves), there is no way around that and one just uses what is available. Jakub