From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id A56B0384D15E for ; Thu, 6 Oct 2022 08:21:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A56B0384D15E 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-ej1-x636.google.com with SMTP id b2so2878495eja.6 for ; Thu, 06 Oct 2022 01:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=RUWlR7I6dwyZK9dCMFqWYN9iTaK36ILsm2huztXYp1g=; b=SsOw0JLjizrYJAOFCGyA2hp/ptWiXRpkXg18sdiIZC7rlURD6aqp3iogt1XK/UoNp5 gq6Yso/qJDnlzIgT22nsMyW0F98QMSYtPxQSDP33qdZWBdr2bGrH8uPBodcIhsIdzFtq l/phHdRaHLsLUK8YatvIC+yRLoMYr5zDb5iBbrrUL1PDrX4kuBg3MdEvRE+LyHGZTdJh bPot5aGuCmnZFjC8ZtxX6GF1BU5w5zjX3hSlKfH9GUQTp55f9+zRtZqIbtkkewFI1CFF b8zP1LBD4aaSXvpshcpD8kkWULQH56pPeoSWrmSp1ArBgfc4AUvEae37wkvjl8sfeCIV GUrQ== 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; bh=RUWlR7I6dwyZK9dCMFqWYN9iTaK36ILsm2huztXYp1g=; b=OqvvmluGl+N/e2/W61LLgY0vHyejjOJq7KEXBNchjp9pFeqVoefaGzGOvjaRtd36R4 TVIqeI8bqMeP/2B0vKmD8Dc3oZU74A0cnXQWj/v9NW/BJk2ixHg3oXNmQcg2slLT8dVV d76Rnp2CZCjrtytdRZNg6h9GFgMYJ0aNjvYvUSpoeThDJWOzirCwN+6COzg0ApaAeIZh 11C+Gh+1+kMgHnmo3haXUngsO0HflqqrHq6/FuLYrFbsfCgDFc0l4vV3DwDDW7dOcIK3 +MKXJdAb+my+Md3vMFCrgmBQZCn2rElqzQtskk1g0iwYeJtUiSBx7mcSMzhAJikzpLYr pE/A== X-Gm-Message-State: ACrzQf24sKZxDpI6SBeuet0lT9KW7JWEr/olY5cA4yHnZBKIYlfYpNro H2+VwA5NUyN1z+tTJHhekriPNZ37ic41qiiCWeM= X-Google-Smtp-Source: AMsMyM4L+yooutspFQvqKBDaXzYZR2xtVNZ3UCT9tXvwSAmapwnNGCEuODKGOCz5+uTiNTljbBWSIK1CqRESZKwebk0= X-Received: by 2002:a17:907:1de1:b0:78d:20bb:3934 with SMTP id og33-20020a1709071de100b0078d20bb3934mr3136978ejc.29.1665044478240; Thu, 06 Oct 2022 01:21:18 -0700 (PDT) MIME-Version: 1.0 References: <4094054.1IzOArtZ34@fomalhaut> In-Reply-To: <4094054.1IzOArtZ34@fomalhaut> From: Richard Biener Date: Thu, 6 Oct 2022 10:21:06 +0200 Message-ID: Subject: Re: [PATCH] Fix wrong code generated by unroll-and-jam pass To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Wed, Oct 5, 2022 at 5:39 PM Eric Botcazou via Gcc-patches wrote: > > Hi, > > as shown by the attached testcase, there is a loophole in the unroll-and-jam > pass that can quickly result in wrong code generation. The code reads: > > if (!compute_data_dependences_for_loop (outer, true, &loop_nest, > &datarefs, &dependences)) > { > if (dump_file && (dump_flags & TDF_DETAILS)) > fprintf (dump_file, "Cannot analyze data dependencies\n"); > free_data_refs (datarefs); > free_dependence_relations (dependences); > continue; > } > > but compute_data_dependences_for_loop may return true even if the analysis is > reported as failing by compute_affine_dependence for some dependence pair: > > (compute_affine_dependence > ref_a: data[_14], stmt_a: data[_14] = i_59; > ref_b: data[_14], stmt_b: data[_14] = i_59; > Data ref a: > #(Data Ref: > # bb: 12 > # stmt: data[_14] = i_59; > # ref: data[_14]; > # base_object: data; > # Access function 0: scev_not_known; > #) > Data ref b: > #(Data Ref: > # bb: 12 > # stmt: data[_14] = i_59; > # ref: data[_14]; > # base_object: data; > # Access function 0: scev_not_known; > #) > affine dependence test not usable: access function not affine or constant. > ) -> dependence analysis failed > > Note that this is a self-dependence pair and the code for them reads: > > /* Nothing interesting for the self dependencies. */ > if (dra == drb) > continue; > > This means that the pass may reorder "complex" accesses to the same memory > location in successive iterations, which is OK for reads but not for writes. > > Proposed fix attached, tested on x86-64/Linux, OK for all active branches? + if (DR_IS_WRITE (dra) + && !DR_ACCESS_FNS (dra).is_empty () + && DDR_ARE_DEPENDENT (ddr) == chrec_dont_know) + { I'm wondering if testing DR_IS_WRITE (dra) is enough here and whether the logic also applies to RAW and WAR. So should it be either (DR_IS_WRITE (dra) || DR_IS_WRITE (drb)) or DR_IS_WRITE (dra) && DR_IS_WRITE (drb) instead? Otherwise thanks for catching. Richard. > > 2022-10-05 Eric Botcazou > > * gimple-loop-jam.cc (tree_loop_unroll_and_jam): Bail out for a self > dependency that is a write-after-write if the access function is not > affine or constant. > > > 2022-10-05 Eric Botcazou > > * gcc.c-torture/execute/20221005-1.c: New test. > > -- > Eric Botcazou