From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 7DCAA3858437 for ; Tue, 30 Jan 2024 10:40:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DCAA3858437 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7DCAA3858437 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706611253; cv=none; b=PwI2Rgqqr/q1ztnG9QfRsY50Z5MbBvH33wIvleyx1h3UXm8y8SG+RoocoqNoeA51WZTOhWZpuS0zvYjPQUbqn5RA46oAJmFxBU3XHV20MSqrWqyNnJNW124KI7z44EtV5a5e1bBJQn4G5pi6JPdvdD9ILax7Xt7/YiWPjpl+yDM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706611253; c=relaxed/simple; bh=E4duG+/7JaflDoU70FkxYnDc0M51jJaoJr+NYqkTkbU=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=jUYHjqglcrXvelbZ24CtsLYoEkltYKSul2dPSLJ4KgtLPak6GJnZL6HZU4XEZ9eHtR0aYC7DXKroIwA2/ZccEzk2VP8cp8KB8ZiOJJ2UDWQzhzrQr3soPFFagzuRJOzTAz5OpM8XSuUdHy/uOrpb4B2caLznQ6V6G7je2q6x/7M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CA7A5DA7; Tue, 30 Jan 2024 02:41:34 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1D0573F5A1; Tue, 30 Jan 2024 02:40:50 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Tamar Christina , gcc-patches@gcc.gnu.org, nd@arm.com, Richard.Earnshaw@arm.com, Marcus.Shawcroft@arm.com, Kyrylo.Tkachov@arm.com, richard.sandiford@arm.com Cc: Tamar Christina , gcc-patches@gcc.gnu.org, nd@arm.com, Richard.Earnshaw@arm.com, Marcus.Shawcroft@arm.com, Kyrylo.Tkachov@arm.com Subject: Re: [PATCH]AArch64: relax cbranch tests to accepted inverted branches [PR113502] References: Date: Tue, 30 Jan 2024 10:40:48 +0000 In-Reply-To: (Richard Biener's message of "Tue, 30 Jan 2024 08:18:31 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.2 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Richard Biener writes: > On Mon, Jan 29, 2024 at 5:00=E2=80=AFPM Richard Sandiford > wrote: >> >> Tamar Christina writes: >> > Hi All, >> > >> > Recently something in the midend had started inverting the branches by= inverting >> > the condition and the branches. >> > >> > While this is fine, it makes it hard to actually test. In RTL I disab= le >> > scheduling and BB reordering to prevent this. But in GIMPLE there see= ms to be >> > nothing I can do. __builtin_expect seems to have no impact on the cha= nge since >> > I suspect this is happening during expand where conditions can be flip= ped >> > regardless of probability during compare_and_branch. >> > >> > Since the mid-end has plenty of correctness tests, this weakens the ba= ckend >> > tests to just check that a correct looking sequence is emitted. >> > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> > >> > Ok for master? >> > >> > Thanks, >> > Tamar >> > >> > gcc/testsuite/ChangeLog: >> > >> > PR testsuite/113502 >> > * gcc.target/aarch64/sve/vect-early-break-cbranch.c: Ignore exac= t branch. >> > * gcc.target/aarch64/vect-early-break-cbranch.c: Likewise. >> >> OK I guess, since I agree that the "polarity" of the branch isn't really= the >> thing that we're trying to test. But the fact that even __builtin_expect >> doesn't work seems like a bug. Do we have a PR for that? Might be worth >> filing one (for GCC 15+) if we don't. > > But that only should affect which edge is fallthru, not the "polarity" > of the branch, no? Right, that's what I meant by "polarity". I should have used a proper term, sorry. The conditions in the patch are inverses of each other, but it seems like the choice between them should be predictable if the branch is very likely or very unlikely. Thanks, Richard