From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id C67813858D32; Thu, 13 Apr 2023 10:01:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C67813858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.98,341,1673942400"; d="scan'208";a="2306877" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 13 Apr 2023 02:01:52 -0800 IronPort-SDR: MY8mhfKh9bdLywf6fRqnsLSea+QAFbhA+QIWYJNwAagSsYsBN8RSy28oKpaFJvCc0gTS1nNJGU zs8jiN4X7hDHpfvP9RdVejP+NmH6esLmVGpc2dvk7WtSIY1pHnaEj235c+d3mUqJ3kz4GvES1O TvQ7CN/qrFYbTDV32Au6euJyQn6yHITeBbnABBD8YWr5/Dsp6Tewj+K5Ap8xQQoNYPY/3wCXpN NRmdyDi3kjfCnIxY8bdB9VDimhPZYmYXwT6APEGXwzqqnGXaN6H4yGIFyBLu0Ocqz8AX04V4U6 TL8= Message-ID: Date: Thu, 13 Apr 2023 11:01:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: 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 To: Andre Simoes Dias Vieira , "gcc-regression@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" , "haochen.jiang@intel.com" References: <202304130148.33D1mmns1987590@shliclel4214.sh.intel.com> Content-Language: en-GB From: Andrew Stubbs In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > 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 > 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)