From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id E0F763858D20; Thu, 13 Apr 2023 14:01:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E0F763858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x135.google.com with SMTP id u12so1565733lfu.5; Thu, 13 Apr 2023 07:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681394494; x=1683986494; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BF2+T13PUASjOwK990azfAibBD5NIKwfAVGcqgLDwA4=; b=mby22oBivIdy04MD9iaSmpMug2byWmM4Mxwcrj50O4bwfSAFbCBFkiKOPnyJ9KKiqA 7OvF35A3Kk/2dsS0RtkuSLqexCLbNhomLd1VPGcqr5qr6AnYTj8XqM2OxvIr1TcWtBVH PFVy6gIJZjYcMoF+g5ZyKdgipwTLKmTO95X5/TbVM8/uBnIVDbjMDtnESbb/1WdKZvoE j/t7mBg6t0v7LPWpcqBXe1VixDakvS8hra3J+nh43vTHgniOsFOELkQ2elG5fvzMraxe k8bIn+5LbwVlgdu4IkOgoyVTchmAdmFVEDUv/6OVp0CgiOYHZO92EPSnBvQvSdxL3AEM 3RwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681394494; x=1683986494; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BF2+T13PUASjOwK990azfAibBD5NIKwfAVGcqgLDwA4=; b=BEfzsodEi0BvCjnFyUgMsbvU988uOvS1pU/j+rCi73n+xc1Pr79GU1zt1/5YO9nU96 CQTP6jTDt8GoFvGre0uXvLEgnjxnujwq3p1gaVH6dqdUbHIIu8IIMaJb9XUc7ivtvTTw yOKKTyINL2BNSC3v29Yyt009JG0Q9K+oCIDwXjvfC/z8xGM+kr0313A/fk19kJjzUQxS MFt/TyBvLxLYooArX6u4fZI7ZjYHf/0Lc32yZXeORUmBTY/mBz+sEUlvsgRzXOV9IKQW MHW+Sa8ZLSLEwRLhmDo58mxCdUZ6/2OVF//jRpCLFnbU6P2lcynLcqnpsJTH/+AYhZ52 Pg/Q== X-Gm-Message-State: AAQBX9cTQc6OywHsO5r7Rk+iW6LaphIDSss97XP8PwxWGKN8tEC4yv6g UhV7/fG5QidIm6M8ENEe/k+bMsPS30QxzL3p96A= X-Google-Smtp-Source: AKy350bO7tfGvKuDswzfxQmqfBsihLW7S5G21obPCW92x2NS0Oa8U6oVk0QcP91AjyxH2/TvtdJA3uD1BGNcoQRrrsA= X-Received: by 2002:ac2:544e:0:b0:4ea:fc8f:7852 with SMTP id d14-20020ac2544e000000b004eafc8f7852mr833180lfn.12.1681394493890; Thu, 13 Apr 2023 07:01:33 -0700 (PDT) MIME-Version: 1.0 References: <202304130148.33D1mmns1987590@shliclel4214.sh.intel.com> <341dd608-a512-3c74-303d-1942876a3850@arm.com> In-Reply-To: <341dd608-a512-3c74-303d-1942876a3850@arm.com> From: Richard Biener Date: Thu, 13 Apr 2023 16:00:34 +0200 Message-ID: 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 Vieira (lists)" Cc: Andrew Stubbs , "gcc-regression@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" , "haochen.jiang@intel.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Apr 13, 2023 at 3:00=E2=80=AFPM Andre Vieira (lists) via Gcc-patche= s wrote: > > > > On 13/04/2023 11:01, Andrew Stubbs wrote: > > Hi Andre, > > > > I don't have a cascadelake device to test on, nor any knowledge about > > what makes it different from regular x86_64. > > Not sure you need one, but yeah I don't know either, it looks like it > fails because: > in-branch vector clones are not yet supported for integer mask modes. > > A quick look tells me this is because mask_mode is not VOIDmode. > i386.cc's TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN will set > mask_mode to either DI or SI mode when TARGET_AVX512F. So I suspect > cascadelake is TARGET_AVX512F. > > This is where I bail out as I really don't want to dive into the target > specific simd clone handling of x86 ;) > > > > > 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 th= e > > tests should behave differently, then the actual expectations need to b= e > > 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 ar= e > > fixed expressions and some run the compiler to probe the configuration, > > but in this case you probably want to do something with "check-flags". > > Even though I agree with you, I'm not the right person to do this > digging for such target specific stuff. So for now I'd probably suggest > xfailing this for avx512f. > > > > 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. > > I mistaken the current behaviour for unrolling, it's actually because of > a latent bug. The vectorizer calls `vect_get_smallest_scalar_type` to > determine the vectype of a stmt. For a function like foo, that has the > same type (long long) everywhere this wouldn't be a problem, however, > because you transformed it into a MASK_CALL that has a function pointer > (which is 32-bit in -m32) that now becomes the 'smallest' type. > > This is all a red-herring though, I don't think we should be calling > this function for potential simdclone calls as the type on which the > veclen is not necessarily the 'smallest' type. And some arguments (like > uniform and linear) should be ignored anyway as they won't be mapped to > vectors. So I do think this might have been broken even before your > changes, but needs further investigation. > > 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. > > The latest commit to these tests was mine, it's the one Haochen is > reporting this regression against. My commit was to fix the issue richi > had introduced that was preventing the feature you introduced from > working. The reason nobody noticed was because the tests you introduced > didn't actually test your feature, since you didn't specify 'inbranch' > the omp declare simd pragma was allowing the use of not-inbranch simd > clones and the vectorizer was being smart enough to circumvent the > conditional and was still able to use simdclones (non inbranch ones) so > when the inbranch stopped working, the test didn't notice. > > The other changes to this test were already after the fix for 108888 > that broke the inbranch feature you added, and so it was fixing a > cascadelake testism but for the not-inbranch simdclones. So basically > fixing a testism of a testism :/ > > > I am working on simdclone's for AArch64 for next Stage 1 so I don't mind > looking at the issue with the vectype being chosen wrongly, as for the > other x86 specific testisms I'll leave them to someone else. Btw, the new testsuite FAILs could be just epiloge vectorizations, so maybe try the usual --param vect-epilogues-nomask=3D0 ... > Kind Regards, > Andre