On Wed, Nov 22, 2017 at 3:17 PM, Richard Sandiford <richard.sandif...@linaro.org> wrote: > Jakub Jelinek <ja...@redhat.com> writes: >> On Wed, Nov 22, 2017 at 02:51:09PM +0100, Richard Biener wrote: >>> On Wed, Nov 22, 2017 at 10:30 AM, Richard Sandiford >>> <richard.sandif...@linaro.org> wrote: >>> > r254589 was supposed to leave tests unchanged for the default setting >>> > of VECTOR_BITS, but I must have got my sums wrong on pr81136.c. >>> > Sorry for the breakage. >>> > >>> > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu, >>> > OK to install? >>> >>> Ok. >> >> That will still FAIL e.g. with -march=skylake-avx512 or -march=knl >> (at least when not preferring 256 or 128 bit vectors), those would need >> ALIGNMENT 64. > > Yeah, the real fix for AVX512 is to define VECTOR_BITS. And I'd have > thought even AVX2 would need to define it to get clean results on other > tests. But the patch that introduced VECTOR_BITS just wasn't supposed > to be changing the default behaviour in the way that I'd accidentally > done here. > > Do you know what the vect.exp results are like for 256-bit and 512-bit > vectors on x86_64? Like I said in the PR, I was surprised we were the > first to hit the need for a macro like VECTOR_BITS. The results for > -msve-vector-bits=256 and -msve-vector-bits=512 were really poor without > it, since many things were hard-coded to values that made sense for > <= 128-bit (or sometimes <= 256-bit) vectors.
IIRC testresuits for -mavx2 were clean (at some point...). Never checked -mavx512[bf] as I don't have AVX512 HW conveniently available. Richard. > Thanks, > Richard
