On Thu, Mar 09, 2017 at 09:15:05AM +0000, Kyrill Tkachov wrote: > Hi all, > > This patch fixes the vec_select errors found by Jakub's genrecog validation > improvements: > ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select > operand is not a vector mode > ../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select > operand is not a vector mode > ../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select > operand is not a vector mode > ../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select > operand is not a vector mode > ../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select > operand is not a vector mode > > The first four are in the DUP and INS lane patterns. They iterate over the > VALL_F16 or VALL mode iterators that include V2DI and V2DF. The VSWAP_WIDTH > attribute for these modes are the scalar DI and DF, which are not > valid as modes of a vec_select operand. > > The problematic patterns deal with lane copies between elements of 64-bit > vectors to 128-bit vectors and vice versa. 64 to 64-bit and 128 to 128-bit > copies are handled in separate patterns (aarch64_dup_lane<mode> and > *aarch64_simd_vec_copy_lane<mode>). > > But there is no variant of those instructions to copy a 64-bit element from a > 128-bit vector to a 64-bit vector (A DUP V<n>.1D, V<m>.D[0] for example). > > Similarly, there is no INS instruction to move from a 128-bit vector of 2 > 64-bit elements to a 64-bit "vector" of one 64-bit element. James also > noticed that these patterns don't handle HFmode, so this patch also adds that > to their iterator. > > The last error is the *aarch64_vgetfmulx<mode> pattern. It uses the VDQF_DF > iterator on the vec_select argument. But VDQF_DF includes DFmode, which is > scalar and thus not valid here. > > I think the best course of action here is to not iterate over DFmode in this > pattern. It's not clear what a vec_select was intended to express for that > case and there are other patterns that do a fmulx on scalar 64-bit operands. > Removing the DFmode from the iterated > modes fixes the error and the relevant intrinsics tests run just fine (plus > some other more rigorous AdvSIMD intrinsics tests that I run). > > With these fixes the genrecog validation doesn't complain for aarch64. > Bootstrapped and tested on aarch64-none-linux-gnu. > > Ok for trunk?
OK. Thanks, James > 2017-03-09 Kyrylo Tkachov <kyrylo.tkac...@arm.com> > > PR target/79913 > * config/aarch64/iterators.md (VALL_F16_NO_V2Q): New mode iterator. > (VALL_NO_V2Q): Likewise. > (VDQF_DF): Delete. > * config/aarch64/aarch64-simd.md > (aarch64_dup_lane_<vswap_width_name><mode>): Use VALL_F16_NO_V2Q > iterator. > (*aarch64_simd_vec_copy_lane_<vswap_width_name><mode>): Use > VALL_NO_V2Q mode iterator. > (*aarch64_vgetfmulx<mode>): Use VDQF iterator.
