Re: [r13-7135 Regression] FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2 on Linux/x86_64

[Andrew Stubbs <ams@codesourcery.com>]

Hi Andre,

I don't have a cascadelake device to test on, nor any knowledge about 
what makes it different from regular x86_64.

If the cascadelake device is supposed to work the same as other x86_64 
devices for these vectors then the test has found a bug in the compiler 
and you should be looking to fix that, not fudge the testcase.

Alternatively, if the device's capabilities really are different and the 
tests should behave differently, then the actual expectations need to be 
encoded in the dejagnu directives. If you can't tell the difference by 
looking at the "x86_64*-*-*" target selector alone then the correct 
solution is to invent a new "effective-target" selector. There are lots 
of examples of using these throughout the testsuite (you could use 
dg-require-effective-target to disable the whole testcase, or just use 
the name in the scan-tree-dump-times directive to customise the 
expectations), and the definitions can be found in the 
lib/target-supports.exp and lib/target-supports-dg.exp scripts. Some are 
fixed expressions and some run the compiler to probe the configuration, 
but in this case you probably want to do something with "check-flags".

For the unroll problem, you can probably tweak the optimization options 
to disable that, the same as has been done for the epilogues feature 
that had the same problem.

Since these are new tests for a new feature, I don't really understand 
why this is classed as a regression?

Andrew

P.S. there was a commit to these tests in the last few days, so make 
sure you pull that before making changes.
On 13/04/2023 10:15, Andre Simoes Dias Vieira wrote:
> Hi,
> 
> @Andrew: Could you have a look at these? I had a quick look at 17f.c and it looks to me like the target selectors aren't specific enough. Unfortunately I am not familiar enough with target selectors (or targets for that matter) for x86_64. From what I could tell with -m32 gcc decides to unroll the vectorized loop so you end up with 4 simdclones rather than the 2 it tests for, GCC probably uses a different cost structure for -m32 that decides it is profitable to unroll?
> 
> As for -march=cascadelake, that seems to prevent gcc from using the inbranch simdclones altogether, so I suspect that cascadelake doesn't support these inbranch simdclones or the vector types it is trying to use.
> 
> Kind regards,
> Andre
> 
> ________________________________________
> From: haochen.jiang <haochenj@ecsmtp.sh.intel.com>
> Sent: Thursday, April 13, 2023 2:48 AM
> To: Andre Simoes Dias Vieira; gcc-regression@gcc.gnu.org; gcc-patches@gcc.gnu.org; haochen.jiang@intel.com
> Subject: [r13-7135 Regression] FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2 on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 58c8c1b383bc3c286d6527fc6e8fb62463f9a877 is the first bad commit
> commit 58c8c1b383bc3c286d6527fc6e8fb62463f9a877
> Author: Andre Vieira <andre.simoesdiasvieira@arm.com>
> Date:   Tue Apr 11 10:07:43 2023 +0100
> 
>      if-conv: Restore MASK_CALL conversion [PR108888]
> 
> caused
> 
> FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 3
> FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2
> FAIL: gcc.dg/vect/vect-simd-clone-17e.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 3
> FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2
> FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 3
> FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-7135/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> 
> To reproduce:
> 
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16e.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16e.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16f.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16f.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17e.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17e.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17f.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17f.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c --target_board='unix{-m32\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact me at haochen dot jiang at intel.com)