On Thu, Jul 20, 2017 at 9:47 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> Another thing is that we actually don't permit a normal move instruction > for V4TImode unless AVX512BW, so we used to generate terrible code (spill it > into memory using GPRs and then load back). Any reason for that? > I've found: > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01465.html >> > > - (V2TI "TARGET_AVX") V1TI >> > > + (V4TI "TARGET_AVX") (V2TI "TARGET_AVX") V1TI >> > >> > Are you sure TARGET_AVX is the correct condition for V4TI? >> Right! This should be TARGET_AVX512BW (because corresponding shifts >> belong to AVX-512BW). > but it isn't at all clear what shifts this is talking about. This is VMOVE, > which is used just in mov<mode>, mov<mode>_internal and movmisalign<mode> > patterns, I fail to see what kind of shifts would those produce. > Those should only produce vmovdqa64, vmovdqu64, vpxord or vpternlogd insns > with %zmm* operands, those are all AVX512F already. In the context of referred message, V1TImode was introduced some time ago to distinguish 128 bit SSE2 pslldq/psrldq insn from scalar TImode double-mode shift (otherwise TImode value could be moved to and from XMM register in a semi-random way to accomodate SSE shift insn). Later, similar V2TImode AVX shifts were introduced and even later AVX512BW V4TImode shifts were introduced. Since the only user of these modes were SSE2/AVX/AVX512BW shifts, it made sense to enable these moves only for corresponding ISAs. In your case, I see no problem to enable V4TImode moves for AVX512F, as long as mov<mode>_internal is able to handle the mode. Uros.
