From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C0A773858D3C for ; Mon, 17 Oct 2022 13:59:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0A773858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666015142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jhwvEUOkmzrAeZWCYnJ3mCJx2YmW5gwyM70MN2TKVAM=; b=cnSNbiDD4oMe8Nrealrju6m5KoIZimsxTD4XjY9IyKHpGoKpCxOuX3pquEuSIlw3gNshek kyz1aJvjScsb7zThciUvskXLOYMFbDqzYrwp+azcjRdIrq7ToB+jMvL3MKeOu2y/8/OQCa 8IpmJSHvSyW8IEgszZ1BjptBGagBpPo= Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-576-j2ViaIZoO6KHEAVX6KsnEg-1; Mon, 17 Oct 2022 09:58:59 -0400 X-MC-Unique: j2ViaIZoO6KHEAVX6KsnEg-1 Received: by mail-yb1-f199.google.com with SMTP id e15-20020a25370f000000b006be3091eee2so10731333yba.10 for ; Mon, 17 Oct 2022 06:58:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=jhwvEUOkmzrAeZWCYnJ3mCJx2YmW5gwyM70MN2TKVAM=; b=s+6QjF/2ToDJ2FZf5Ygs/M5FTcVBJbMH4aoT0rPX8rUi82gfBuxtENJPg0cS/MbN/c gIPfj3a4M1CnF2lmCK1AodZ6g5jDouGPj9QkUkWK5zfeVyn8G+vU73TwKDux3oV7AKiP APfudX2R9RVvwDpCf+37ucQlRip4HRIpsBvmOhT7EOlszqHXGZocGZNtzwvKPBdUmJyL oSMv71IrYKvwpwtL+/1pvtDoJJUFeLQ0MMEmfSKFhJsJrJd6HxMPSHcrVaEyJ4cW5d10 F5/PkZQO6govFjdAjh/Pz0M0MTBFuv4uPbec42s3BMMB4YbQ7CNHINe6hmbiDBS0nk5p jZrA== X-Gm-Message-State: ACrzQf12S0NZuENEpdILYyb25ixOSM3L6XrCm6Yif5V5FdcaSmWtcO4b ++EZFWbsjXWaW8yv1k2J4591E2DsoMVb2l/Ps6HGRA3THATfEPbdIbx9PJIJXPtm1voL24wYcyF ZsQbbrunrF0KcotQRe+9zXMCbq8c8XQri+A== X-Received: by 2002:a25:6055:0:b0:6be:340a:3757 with SMTP id u82-20020a256055000000b006be340a3757mr8955961ybb.109.1666015138423; Mon, 17 Oct 2022 06:58:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6HgxzUySHE7+yhRQuoA/EjSXk8s/LMzyJSF84ASCXJrPyE9Bzqg//pbNlYZOQBU4Ejh60MOOpA3ocoIQiUEIM= X-Received: by 2002:a25:6055:0:b0:6be:340a:3757 with SMTP id u82-20020a256055000000b006be340a3757mr8955942ybb.109.1666015138066; Mon, 17 Oct 2022 06:58:58 -0700 (PDT) MIME-Version: 1.0 References: <20221011083137.336470-1-aldyh@redhat.com> <878rlej3o6.fsf@euler.schwinge.homeip.net> In-Reply-To: <878rlej3o6.fsf@euler.schwinge.homeip.net> From: Aldy Hernandez Date: Mon, 17 Oct 2022 15:58:47 +0200 Message-ID: Subject: Re: Add 'c-c++-common/torture/pr107195-1.c' [PR107195] (was: [COMMITTED] [PR107195] Set range to zero when nonzero mask is 0.) To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: On Mon, Oct 17, 2022 at 9:44 AM Thomas Schwinge wrote: > > Hi! > > On 2022-10-11T10:31:37+0200, Aldy Hernandez via Gcc-patches wrote: > > When solving 0 = _15 & 1, we calculate _15 as: > > > > [irange] int [-INF, -2][0, +INF] NONZERO 0xfffffffe > > > > The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with > > the above, yielding: > > > > [0, 1] NONZERO 0x0 > > > > This eventually gets copied to a _Bool [0, 1] NONZERO 0x0. > > > > This is problematic because here we have a bool which is zero, but > > returns false for irange::zero_p, since the latter does not look at > > nonzero bits. This causes logical_combine to assume the range is > > not-zero, and all hell breaks loose. > > > > I think we should just normalize a nonzero mask of 0 to [0, 0] at > > creation, thus avoiding all this. > > 1. This commit r13-3217-gc4d15dddf6b9eacb36f535807ad2ee364af46e04 > "[PR107195] Set range to zero when nonzero mask is 0" broke a GCC/nvptx > offloading test case: > > UNSUPPORTED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O0 > PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 (test for excess errors) > PASS: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test > [-PASS:-]{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/nvptx-sese-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 scan-nvptx-none-offload-rtl-dump mach "SESE regions:.* [0-9]+{[0-9]+->[0-9]+(\\.[0-9]+)+}" > > Same for C++. > > I'll later send a patch (for the test case!) to fix that up. > > 2. Looking into this, I found that this > commit r13-3217-gc4d15dddf6b9eacb36f535807ad2ee364af46e04 > "[PR107195] Set range to zero when nonzero mask is 0" actually enables a > code transformation/optimization that GCC apparently has not been doing > before! I've tried to capture that in the attached > "Add 'c-c++-common/torture/pr107195-1.c' [PR107195]". Nice. > > Will you please verify that one? In its current '#if 1' configuration, > it's all-PASS after commit > r13-3217-gc4d15dddf6b9eacb36f535807ad2ee364af46e04 > "[PR107195] Set range to zero when nonzero mask is 0", whereas before, we > get two calls to 'foo', because GCC apparently didnn't understand the > relation (optimization opportunity) between 'r *= 2;' and the subsequent > 'if (r & 1)'. Yeah, that looks correct. We keep better track of nonzero masks. > > I've left in the other '#if' variants in case you'd like to experiment > with these, but would otherwise clean that up before pushing. > > Where does one put such a test case? > > Should the file be named 'pr107195' or something else? The aforementioned patch already has: * gcc.dg/tree-ssa/pr107195-1.c: New test. * gcc.dg/tree-ssa/pr107195-2.c: New test. So I would just add a pr107195-3.c test. > > Do we scan 'optimized', or an earlier dump? > > At '-O1', the actual code transformation is visible already in the 'dom2' > dump: > > [local count: 536870913]: > gimple_assign > + gimple_assign > + goto ; [100.00%] > > - [local count: 1073741824]: > - # gimple_phi > + [local count: 536870912]: > + # gimple_phi > gimple_assign > gimple_cond > - goto ; [50.00%] > + goto ; [100.00%] > else > - goto ; [50.00%] > + goto ; [0.00%] > > [local count: 536870913]: > gimple_call > gimple_assign > > [local count: 1073741824]: > - # gimple_phi > + # gimple_phi > gimple_return > > And, the actual "avoid second call 'foo'" optimization is visiable > starting 'dom3': > > [local count: 536870913]: > gimple_assign > + goto ; [100.00%] > > - [local count: 1073741824]: > - # gimple_phi > - gimple_assign > + [local count: 536870912]: > + gimple_assign > gimple_cond > - goto ; [50.00%] > + goto ; [100.00%] > else > - goto ; [50.00%] > + goto ; [0.00%] > > [local count: 536870913]: > - gimple_call > - gimple_assign > + gimple_assign > + gimple_assign > > [local count: 1073741824]: > - # gimple_phi > + # gimple_phi > gimple_return > > ..., but I don't know if either of those would be stable/appropriate to > scan instead of 'optimized'? IMO, either dom3 or optimized is fine. Thanks. Aldy